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.
Don't be an ass you 'fiber' cretin.
Banned C standard library functions in Git source code
121–130 of 329 posts
Re: Banned C standard library functions in Git source code
#122I'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.
And in all of the CPS code.
Re: Banned C standard library functions in Git source code
#123For 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.
I'm also confused reading that comment, but I suppose the intended link is that GitHub employees are significant git contributors?
Re: Banned C standard library functions in Git source code
#124Earlier quoted context omitted.
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
strlcpy is a terrible alternative. I have never seen it used correctly. It takes more and uglier code to use it correctly than to use strlen and strcpy. People who use it don't bother. 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.
I agree that strlcpy is braindamaged, but why in God's Green Earth isn't there a sensible replacement in stdlib in 2019? This shouldn't be that hard, yet the best alternative is I think snprintf, which is just so ugly. For a long time it wasn't used because compiler support was spotty, but it's been 20 years now so that shouldn't be a major issue anymore.
Re: Banned C standard library functions in Git source code
#125Re: Banned C standard library functions in Git source code
#126Earlier quoted context omitted.
I think you mean fibers, and no you can't.
Here is an implementation of coroutines on top of setjmp/longjmp: https://fanf.livejournal.com/105413.html
How does it work for arbitrary arguments? What about function pointers. What about calling a coroutine inside a coroutine?
It also has a stack managed in runtime. I'm not sure that would work for any other application than the fun example here.
Re: Banned C standard library functions in Git source code
#127Earlier 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.
> not the standard "PR" procedure in GitHub If it is specific to one implementation, then it is not standard, pretty much by definition.
the word "standard" has more than one meaning. it's not standard by the definition of standard that you chose, but you can use your context cues to realize that it's not the definition of standard that OP meant.
Re: Banned C standard library functions in Git source code
#128I'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 did! And the ergonomics are dreadful!
Re: Banned C standard library functions in Git source code
#129Earlier quoted context omitted.
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.
> 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...). 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 m…
The problem isn't exactly reentry. It's that the function, having already exited, has modified global state, and it needs the same state to be there on the next call. If another call is interleaved (another callee with its own strtok loop) then the state is overwritten with the inner loop, and your own next call won't have its expected contents.
Whereas with a term like reentry I think of two strtok frames on the stack at the same time, which is not possible.
I think it's a bit easier to conceptualize with a function that produces a simple return value in a static buffer. Take getpwnam(). It fills a global structure with info about a given user. So you may keep a pointer to that on your stack. Then you call some other function foo(). foo looks up another user. Suddenly you can't rely on that other call to getpwnam() not having overwritten the data in the result you got back the first time.
Re: Banned C standard library functions in Git source code
#130That'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.
Might as well just use strtok_r everywhere and not worry about if you're using strok safely or not.