111–120 of 329 posts
musl libc (an alternative libc) provides implementations of these functions that are memory-safe. (It only works on Linux though.)
Using musl as your standard library causes other problems, namely horrible Python performance and incompatibility with Valgrind.
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…
If every C programmer knew, then there would be no need to ban them
I have seen strtok used, even though it takes more code to use it correctly than not use it. strlcpy is like that, too. Of course, what happens is nobody uses them correctly.
Puts(),gets() would make a good addition?
That's a surprisingly small list, missing e.g. sscanf / gets / strtok / all the other "usual suspects" at least
Earlier quoted context omitted.
I'm not an expert in C, but then what's the issue with strncpy() or any "n" functions? It prevents overflow AFAIK. Also what is the alternative (memcpy?) and why?
strlcpy() is a nice alternative, it's from OpenBSD from 1996. Was later added to the other BSDs, Solaris and macOS. But, last I checked, Linux never added them. :( https://www.sudo.ws/todd/papers/strlcpy.html
Finding use of strlcpy in a program is a red warning of sloppy code.
There are good reasons it was kept out of glibc for so long.
Earlier quoted context omitted.
I don't see a huge problem with strtok as long as it isn't a multi threaded program. It is not in gets territory which is literally impossible to use correctly.
Synchronous reentry is a problem. Say some loop using strtok calls a function... how do you know that that function doesn't use strtok (or call another function that does...). Any use of non-const static variables in general has this problem, and strtok is just one example.
I’m constantly surprised that C isn’t specified in such a way that lack-of-reentrancy can be determined at compile time. You’d “just” need a symbol table, sort of like the debug symbol table, in each compiled object, holding for each visible symbol the set of function calls marked `__no_reenter` that are predominated by that symbol in control flow. (Yes, some functions do computed jumps, like with longjmp. Just implicitly label those functions __no_reenter unless the programmer explicitly labels them __reenter!)
Earlier quoted context omitted.
Nice catch! You can send a "PR", but note that they have their own custom "PR" procedure, not the standard "PR" procedure in GitHub. > Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow https://github.com/git/git/blob/master/Documentation/Submitt... procedure for any of your improvements.
Aside: GitHub’s refusal to provide a feature to close pull requests for mirrors is utterly ridiculous since it requires that people (or bots) go around and disable pull requests and point people to the patch submission process.
I sort of get not allowing it, except that it's inconsistent.
For anybody else: Why is strncpy insecure? https://stackoverflow.com/questions/869883/why-is-strncpy-in... > strncpy() doesn't require NUL termination, and is therefore susceptible to a variety of exploits.
Yes. Also as mentioned in the post, strlcpy (when it's available) is safer.