Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Banned C standard library functions in Git source code

github.com

Post reply on HN
Print view View original

211–220 of 329 posts

Re: Banned C standard library functions in Git source code

#211

Post by timq »

segfaultbuserr wrote: post #157
r3trohack3r wrote: post #131

Earlier quoted context omitted.

I wonder about this every time I read C. There is talk about npm/rust having massive dependency trees (and they do) because it makes taking on dependencies too easy. But I feel like C is on the opposite side of the spectrum, where managing dependencies is difficult so every C code base is rolling it’s own version of everything. C also has an expansive standard library but it hasn’t offset re-invention of that stdlib…

Creating a lightweight library would make C programming much more productive, and I'm sure many have tried, but I wonder why none of them see widespread applications, instead of writing some half-baked, ad-hoc helper functions. One reason, I guess, is the diverse range of applications of C, another reason is the lack of advanced features like generics and templates. But it would still be useful to create a simple lib…

If I had to guess why there are no such lightweight library, it is because when somehow the library API doesn't provide what you want, you cannot hack the library itself easily. If you import the source code you may have trouble building it, and maintening such "patch" is not a lot of fun.

Re: Banned C standard library functions in Git source code

#212

Post by fucking_tragedy »

thomasjames wrote: post #182
mlyle wrote: post #67

Earlier quoted context omitted.

You can build coroutines from them, too, which is really cool and useful.

I had only seen them in the context of userspace threading. I wonder what mainstream libs use them. Do you know of any?

Generators are a subset of coroutines, and coroutines are useful in lexing and parsing.

Re: Banned C standard library functions in Git source code

#213

Post by dezgeg »

jandrese wrote: post #120
vagab0nd wrote: post #64

Earlier quoted context omitted.

Yes. Also as mentioned in the post, strlcpy (when it's available) is safer.

But still not safe, thanks to the return value. Imagine the case where you are using strlcpy because you can't be sure if the source buffer is properly null terminated.

If your buffer isn't a NUL-terminated, then don't call a function that is only defined for NUL-terminated buffers. It's as simple as that.

I'm baffled by how some people claim strlcpy() is 'broken' or 'not safe' because it doesn't handle non-NUL-terminated inputs; the exact same thing applies to just about any function in the C standard library that takes strings as input. Are functions like strchr(), fopen(), printf(), strstr(), setenv() 'broken' as well?

Re: Banned C standard library functions in Git source code

#214

Post by adamnemecek »

jancsika wrote: post #176
r3trohack3r wrote: post #131

Earlier quoted context omitted.

I wonder about this every time I read C. There is talk about npm/rust having massive dependency trees (and they do) because it makes taking on dependencies too easy. But I feel like C is on the opposite side of the spectrum, where managing dependencies is difficult so every C code base is rolling it’s own version of everything. C also has an expansive standard library but it hasn’t offset re-invention of that stdlib…

It's bad that C devs have rolled their own awful, buggy custom solutions. However, here's the upshot-- that awful, buggy, custom solution is guaranteed to remain compatible with the codebase that contains it. You won't find a single instance where such a dev "improved", "refactored", "optimized", or "modernized" that awful, buggy code in a way that stopped the rest of the code from working and then shipped that broke…

This is a C++ dependency manager problem though.

Re: Banned C standard library functions in Git source code

#215

Post by zxcvbn4038 »

codedokode wrote: post #210

What surprises me in C developers is that C exists for probably 40 years but they still don't have proper strings (not just pointers). In many cases there is no large performance penalty for storing string length, and checking it, but they still use pointers or a separate pair of variables for pointer and buffer size instead of single object.

There are countless libraries that add higher level string functions and no end to higher level languages. C fills the niche where you want something higher level then assembly but lower level then Perl, ruby, python, etc. Sometimes you want or need to manage your own memory. Arduino is a good contemporary example.

Re: Banned C standard library functions in Git source code

#216

Post by noname120 »

noname120 wrote: post #75
asveikau wrote: post #37

Earlier quoted context omitted.

A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…

That's gatekeeping. If a junior developer starts working on this project they might bother a more senior developer who has better things to do with their time, or inline the definition of one of the functions out of frustration.

I'd be interested in knowing which part of the comment you don't agree with and why.

Re: Banned C standard library functions in Git source code

#217

Post by mhh__ »

MrStonedOne wrote: post #199
asveikau wrote: post #37

Earlier quoted context omitted.

A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…

I'm a c programmer, I'm reading this list, I don't know why they are there. You. Can. Not. Call. Yourself. Open. Source. If. You. Gatekeep. Your. Contributors.

I think you can. The whole point of being open source and using a project like cough git (since we're here), is that if you don't like it you can fork it. If you don't allow forks then I agree you aren't open source

Re: Banned C standard library functions in Git source code

#219

Post by mhh__ »

winter_blue wrote: post #39

musl libc (an alternative libc) provides implementations of these functions that are memory-safe. (It only works on Linux though.)

If you have a critical need for memory safety then I think it's time to move on from C.

I also have a (I guess?) Slightly unpopular opinion, that C is actually really ugly. Subjective, but C code is usually prone to repeating itself a lot or abstracting in an unsafe manner

Re: Banned C standard library functions in Git source code

#220

Post by stjohnswarts »

zxcvbn4038 wrote: post #215
codedokode wrote: post #210

What surprises me in C developers is that C exists for probably 40 years but they still don't have proper strings (not just pointers). In many cases there is no large performance penalty for storing string length, and checking it, but they still use pointers or a separate pair of variables for pointer and buffer size instead of single object.

There are countless libraries that add higher level string functions and no end to higher level languages. C fills the niche where you want something higher level then assembly but lower level then Perl, ruby, python, etc. Sometimes you want or need to manage your own memory. Arduino is a good contemporary example.

Exactly. C philosophy is to use libraries and not put things like a better string library in the core functions of the language. It keeps the language relatively clean and easy to understand, unlike c++
Post reply on HN