Bunch of cucks who need to gimp themselves, just because they don't feel responsible enough to use a tool.
Banned C standard library functions in Git source code
241–250 of 329 posts
Re: Banned C standard library functions in Git source code
#242Earlier 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…
You had the unfair advantage of working on your own :)
Re: Banned C standard library functions in Git source code
#243Re: Banned C standard library functions in Git source code
#244Earlier quoted context omitted.
> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...
No flaw with math/stats here, that can actually happen. I think you're confusing average/mean with median (50-percentile). PS: I'm not sure where he's getting his numbers though
I'm 99% sure that was tongue in cheek.
Re: Banned C standard library functions in Git source code
#245Re: Banned C standard library functions in Git source code
#246Earlier quoted context omitted.
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…
Yes, because cutting off the trailing NULL is a threat vector every C programmer needs to be conscious of whenever they're dealing with strings.
But it's also a problem because maybe the programmer is using strlcpy to grab the first five lines of a 10TB memory mapped file. If you're not thinking about the implications of that return value it can be a real surprise.
Re: Banned C standard library functions in Git source code
#247Earlier quoted context omitted.
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…
> If your buffer isn't a NUL-terminated, then don't call a function that is only defined for NUL-terminated buffers.
It's not that people want to pass strncpy source buffers that lack NUL termination, it's that strncpy in certain situations will not NUL terminate its results.
https://begriffs.com/posts/2019-01-19-inside-c-standard-lib....
> some people claim strlcpy() is 'broken'
Speaking of strlcpy, it thankfully doesn't have the problem that strncpy does. However strlcpy is not in the C standard or in POSIX, so can't be used portably. In C99 snprintf is a better choice.
Re: Banned C standard library functions in Git source code
#248Earlier quoted context omitted.
You can build coroutines from them, too, which is really cool and useful.
I don't know why I still remember these, but if you need to build coroutines in C, ucontext.h might be a better tool: https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h...
Those are deprecated.
Re: Banned C standard library functions in Git source code
#249If that header is ever accidentally included before any standard header, it's undefined behavior. :)
How? The preprocessor is ran before every thing else? It will overwrite the defintions in the header just like in the source file? You still would get a linking error. The only reason I couldn think is if the the stdlib headers also called undef for those functions. Moreover this is all during build not runtime.
Re: Banned C standard library functions in Git source code
#250If I had time, I'd make a library (perhaps musl-based?) that implements "libc but without all the parts you're not actually supposed to use."
That make me wonder how hard it would be to just strip the bad functions out of the library.
Well your std c library is generally just a collection of .o, .a, .lib files. So you could use gnu bin tools to remove symbols of your choosing. However good luck getting your system to build software because that would modify the stdlib for all things compiled on your system. You could also tell gcc or clang not to link to the std library and providr your own with just a few switches on invocation of the compiler