Earlier quoted context omitted.
You can build coroutines from them, too, which is really cool and useful.
I think you mean fibers, and no you can't.
[deleted]
Banned C standard library functions in Git source code
101–110 of 329 posts
Re: Banned C standard library functions in Git source code
#102Re: Banned C standard library functions in Git source code
#103Earlier quoted context omitted.
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?
If the strcp() macro is used with a function as the first argument (or an expression that has side-effects), it's not obvious at the call site (or, probably, intended by the programmer) that the argument will be evaluated twice.
E.g. suppose we write something like
char* buf = strcp(((char*)malloc(4)), "foobar", 4);
If strcp were a function, its first argument would be evaluated just once, and it would work as intended.
Re: Banned C standard library functions in Git source code
#104Earlier quoted context omitted.
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 wha…
longjmp will not interrupt third party code (well maybe if it uses callbacks and you use it from a callback).
setjmp/longjmp will almost certainly require tracking any resource use carefully so that resources can be released at the setjmp point, when execution gets back there.
I mostly use it for terminating the recursive descent parsing on error. Otherwise it gets tedious to check return values everywhere in hand written code.
Re: Banned C standard library functions in Git source code
#105I'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
> If it's used at all these days, it's used for exception handling.
What about co-routines?
Re: Banned C standard library functions in Git source code
#106For context, this header file was introduced during the period of Microsoft's acquisition of GitHub. Git's banned.h roughly approximates the banned functions according to Microsoft's Security Development Lifecycle: https://docs.microsoft.com/en-us/previous-versions/bb288454(... It seems Microsoft once published their own banned.h, but this file is not readily available from the MSDN anymore.
What are you saying is the connection between GitHub's acquisition and this header? This code is from git, not GitHub.
Re: Banned C standard library functions in Git source code
#107Earlier quoted context omitted.
What's a good library for this kind of boilerplate? A lightweight one if possible, i.e. not fucking glib
Salvatore Sanfilippo, from Redis fame, has a nice one https://github.com/antirez/sds .
I'd rather make it explicit that returned/passed value is something other than a regular zero terminated string. Otherwise you can easilly make a mess, if you pass zero terminated string to a function that expects some special bytes in the memory before the pointer.
Re: Banned C standard library functions in Git source code
#108Earlier 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 actually wonder why they do it.
Linkers already warn for this stuff. Doing it this way requires every source file to include banned.h, which I would guess is done by including it from some other common header, but that's not fool proof either.
Re: Banned C standard library functions in Git source code
#109I'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 don't use setjmp() and longjmp() often, but sometimes I do; I use goto more often than those (but still not all the time). (I want goto in JavaScript too. I figured out a algorithm to do so, but have not implemented it.)
One use of setjmp/longjmp I have used is in ZORKMID, to deal with the debugger. At the beginning of the execute() function I have:
while(setjmp(exception_buffer));
Re: Banned C standard library functions in Git source code
#110Earlier 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…
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).
I don't remember how I learned this. But it happens pretty naturally working with C a lot and doing things like reading documentation and code. To be clear this is not elitism or something of the sort, I am not at all pessimistic that new people won't learn it. It just needs to happen in its due time.
So I would say... What good is a verbose comment to explain? Somebody who doesn't instantly understand why it's banned can read the big warnings on the manpage, or they can google it and land on good explanations on sites like Stack Overflow, or they can look at the function signatures and come up with a correct guess. Then boom. They know. And from there they can assess other interfaces and see if they suffer the same weakness.
This ability tends to come from simple exposure.