Huh, I literally just read through this file a few minutes before this was posted because I was randomly browsing the git source code.
Banned C standard library functions in Git source code
81–90 of 329 posts
Re: Banned C standard library functions in Git source code
#82musl 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.
Re: Banned C standard library functions in Git source code
#83Why is there no brief explanations in this code why each function is banned?
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…
You explained it in 2 lines that would make for great comments.
It seems useful to educate C programmers who don't have "significant experience" because, well, by definition, not every C programmer has "significant experience" and they are the ones who would benefit most from learning this.
It's not about being controversial: nobody's going to disagree with your explanation (it is what it is - it's not an opinion).
Re: Banned C standard library functions in Git source code
#84Earlier quoted context omitted.
strncpy() does not guarantee that the copied string would be terminated with a null byte ('\0'). For a call that looks like strncpy(dst, src, n), if there is no null byte in the first n bytes of src, the string copied to dst would also not contain a null byte. Here is an example code to demonstrate the problem: #include #include int main() { char a[] = "01234567"; strncpy(a, "foobar", 4); printf("%.8s\n", a); return…
Your macro refers to a twice; it might be better as a function.
What has referring to a variable twice got to do with whether it should be a macro or function?
Re: Banned C standard library functions in Git source code
#85That's a surprisingly small list, missing e.g. sscanf / gets / strtok / all the other "usual suspects" at least
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.
Re: Banned C standard library functions in Git source code
#86FWIW, here's awesome-static-analysis > Programming Languages > C/C++: https://github.com/mre/awesome-static-analysis/blob/master/R...
These tools have lists of functions not to use. Most of them — at least the security-focused ones — likely also include: strcpy, strcat, strncpy, strncat, sprints, and vsprintf just like banned.h
Re: Banned C standard library functions in Git source code
#87I'm glad to see that setjmp() and longjmp() are still allowed. I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling. More info: https://en.wikipedia.org/wiki/Setjmp.h
You can build coroutines from them, too, which is really cool and useful.
I think you mean fibers, and no you can't.
Re: Banned C standard library functions in Git source code
#88Why is there no brief explanations in this code why each function is banned?
Because it's git. It's obscure by design.
Re: Banned C standard library functions in Git source code
#89It is also important to teach newbies on the pitfalls of certain libc functions. Too much spoon feeding creates a bigger mess in the long run.
Re: Banned C standard library functions in Git source code
#90Why is there no brief explanations in this code why each function is banned?
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