Why is there no brief explanations in this code why each function is banned?
Look at the commit comments (https://github.com/git/git/commits/master/banned.h)
Banned C standard library functions in Git source code
71–80 of 329 posts
Re: Banned C standard library functions in Git source code
#72Looks like Git has its own string type: https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.c See this for the story of why strncpy/strncat are insecure: https://en.wikipedia.org/wiki/C_string_handling#Replacements
Like essentially all C programs.
Every C programmer has his/her own standard library...
Re: Banned C standard library functions in Git source code
#73There are persons working on git who abuse strcpy()? This sounds a bit like activism and not based on reality.
Re: Banned C standard library functions in Git source code
#74I'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
I think reasonable people can debate this one. setjmp()/longjmp() are very useful when working with libpng [1] and jpeglib [2], as you mentioned, as a crude exception handling mechanism. I have seen these functions used in production safely for that purpose. I can imagine other horrible uses for them though. Unlike things like strcpy() which are security-holes-by-design, setjmp()/longjmp() should be in a "carefully c…
The trouble is how they compose with the expectations of code you don't write. It's just not normal in C to expect execution of your function to abort halfway through, and so memory leaks and broken state are almost guaranteed when they're mixed with the wrong third party library.
It might work great when you wrote it, but it might not even survive the next change to the codebase, and 10 years out, who is to know what programmers will come along and plug new stuff in without noticing the stack magic, etc
edit: another aspect of the same issue is that it can be difficult or impossible to write generic longjmp-safe code for many kinds of tasks. In C++ you have stack unwinding to e.g. delete large temporary heap allocations during a complex operation, but no such facility exists in C.
Re: Banned C standard library functions in Git source code
#75Why 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…
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.
Re: Banned C standard library functions in Git source code
#76#ifndef BANNED_H
#define BANNED_H
/* * This header lists functions that have been banned from our code base, * because they're too easy to misuse (and even if used correctly, * complicate audits). Including this header turns them into compile-time * errors. /
#define BANNED(func) sorry_##func##_is_a_banned_function
#undef strcpy #define strcpy(x,y) BANNED(strcpy) #undef strcat #define strcat(x,y) BANNED(strcat) #undef strncpy #define strncpy(x,y,n) BANNED(strncpy) #undef strncat #define strncat(x,y,n) BANNED(strncat)
#undef sprintf #undef vsprintf #ifdef HAVE_VARIADIC_MACROS #define sprintf(...) BANNED(sprintf) #define vsprintf(...) BANNED(vsprintf) #else #define sprintf(buf,fmt,arg) BANNED(sprintf) #define vsprintf(buf,fmt,arg) BANNED(sprintf) #endif
#endif / BANNED_H */
Re: Banned C standard library functions in Git source code
#77That'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.
"I don't see a huge problem with insert thing here as long as it isn't a multi threaded program."
Usually a bad omen. :)
Re: Banned C standard library functions in Git source code
#78If that header is ever accidentally included before any standard header, it's undefined behavior. :)
Re: Banned C standard library functions in Git source code
#79I'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
I remember setjmp() and longjmp() being the only way to do a STREAMS device driver I wrote 30 years ago. Don't know if things have changed since then. Ah, what memories.
Re: Banned C standard library functions in Git source code
#80I'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
These are used /everywhere/ in PostgreSQL, exactly for exception handling. The result isn't bad at all, but indeed, too powerful a tool for 99% of developers
And that's the perfect usage for goto. Error catching and jump to fail block...