Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Banned C standard library functions in Git source code

github.com

Post reply on HN
Print view View original

171–180 of 329 posts

Re: Banned C standard library functions in Git source code

#171

Post by pjmlp »

userbinator wrote: post #141

Good to see the list is short and relatively sane compared to other "banned function" lists. Unfortunately, "too easy to misuse" is a slippery slope, and gets(), which is probably the best example of a function which is really broken by design, isn't on that list. I'm surprised that "complicate audits" is given as a reason, because isn't this something static analysers (and I mean ones that actually analyse data/code…

As per ISO C11 standard, compliant compilers no longer need to support gets().

Re: Banned C standard library functions in Git source code

#172

Post by pault »

zzo38computer wrote: post #109
alister wrote: post #26

I'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)); (The semicolon is correct; the lo…

What can you accomplish with goto that you can't accomplish with try/catch and custom errors?

Re: Banned C standard library functions in Git source code

#173

Post by rkagerer »

LukeShu wrote: post #41
alister wrote: post #26

I'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

The way I see the list is that it isn't meant to be exhaustive, it's meant to be functions that contributors are likely to try to use. A new contributor might not realize that they should be using Git's internal strbuf.h instead of the libc string functions. It's a way to give them feedback on that from their compiler, before they spend more time on the patch and send it to the mailing list.

Might be nice if the error messages suggested such alternatives instead of just saying "banned"?

Re: Banned C standard library functions in Git source code

#174

Post by Gibbon1 »

jasonhansel wrote: post #142

If I had time, I'd make a library (perhaps musl-based?) that implements "libc but without all the parts you're not actually supposed to use."

That make me wonder how hard it would be to just strip the bad functions out of the library.

Re: Banned C standard library functions in Git source code

#175

Post by winter_blue »

saagarjha wrote: post #166
winter_blue wrote: post #94

Earlier quoted context omitted.

It provides everything that libc does.

So how does it solve the issues with these functions?

It doesn’t — I was wrong.

I was digging through its source code, and it turns out it isn’t memory-safe after all. Here’s the source code for stpcpy: https://github.com/ifduyue/musl/blob/master/src/string/stpcp...

If dest is too small in the function linked to above, musl’s stpcpy will happy cause a buffer overflow.

Don’t know how or from where I got the impression that musl was a “safer” alternative to libc.

Re: Banned C standard library functions in Git source code

#176

Post by jancsika »

r3trohack3r wrote: post #131
segfaultbuserr wrote: post #72

Earlier quoted context omitted.

Every C programmer has his/her own standard library...

I wonder about this every time I read C. There is talk about npm/rust having massive dependency trees (and they do) because it makes taking on dependencies too easy. But I feel like C is on the opposite side of the spectrum, where managing dependencies is difficult so every C code base is rolling it’s own version of everything. C also has an expansive standard library but it hasn’t offset re-invention of that stdlib…

It's bad that C devs have rolled their own awful, buggy custom solutions.

However, here's the upshot-- that awful, buggy, custom solution is guaranteed to remain compatible with the codebase that contains it. You won't find a single instance where such a dev "improved", "refactored", "optimized", or "modernized" that awful, buggy code in a way that stopped the rest of the code from working and then shipped that broken blob of junk. And if you did find that, there's no way they'd convince the rest of the devs that this is a useful thing to do in the interest of "moving forward" or whatever.

On the other hand you'll find zillions of dollars spent on systems to keep dependency management tools from causing exactly that problem.

Just to give a real-world example-- a user reported that an abandoned C++ plugin wasn't working. We did a race:

1. Three devs try to get a single C++ dependency of that plugin to work cross platform (OSX, Windows, Linux).

2. I tried to port the C++ plugin to a C plugin with no deps.

By the time I ported, tested, and shipped, those three devs were tracking down a bug with the build script of the C++ dependency on Windows.

Edit: granted the plugin itself is only about 2000 lines of code.

Re: Banned C standard library functions in Git source code

#177

Post by StreamBright »

sfkdjf9j3j wrote: post #154
StreamBright wrote: post #125

Earlier quoted context omitted.

All of them are null pointer exception & segfault free I bet.

Due to the language's design, C programs are in fact guaranteed to be free of exceptions.

Nitpicking but you are right. Null pointer bugs (null pointer dereference to be precise) are all over the place in C though.

https://stackoverflow.com/questions/4007268/what-exactly-is-...

Re: Banned C standard library functions in Git source code

#178

Post by chucksmash »

vmsp wrote: post #62
zsrxx wrote: post #38

Earlier 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 .

Thanks for linking this, it's always good to see how very strong engineers solve problems. Never in a million years would this approach have occurred to me. For the interested, the README in the linked repo is done well and clearly explains the approach itself as well as pros and cons. This also reminded me that I've been meaning to watch antirez' "Writing System Software"[0] videos on YouTube for quite a while now, so thanks for that too.

[0]: https://www.youtube.com/playlist?list=PLrEMgOSrS_3fghr8ez63x...

Re: Banned C standard library functions in Git source code

#179

Post by ttaylorr »

peff wrote: post #139
jcl wrote: post #33

Looks like the second vsprintf definition should be "BANNED(vsprintf)", not "BANNED(sprintf)". Not that it matters much, as it only affects the error message.

Yes, you're right. Patches welcome. We do our development on a mailing list; see https://git-scm.com/docs/SubmittingPatches for details. However, if you're more comfortable using GitHub PRs, there's a gateway interface at https://gitgitgadget.github.io/ .

I submitted a patch to fix this typo from my fork (which you can see at https://public-inbox.org/git/cab687db8315dd4245e1703402a8c76...).

Re: Banned C standard library functions in Git source code

#180

Post by cyphar »

winter_blue wrote: post #175
saagarjha wrote: post #166

Earlier quoted context omitted.

So how does it solve the issues with these functions?

It doesn’t — I was wrong. I was digging through its source code, and it turns out it isn’t memory-safe after all. Here’s the source code for stpcpy: https://github.com/ifduyue/musl/blob/master/src/string/stpcp... If dest is too small in the function linked to above, musl’s stpcpy will happy cause a buffer overflow. Don’t know how or from where I got the impression that musl was a “safer” alternative to libc.

The API of strcpy() is unsafe by design. The only way to make it safe is to not use it, and it's not musl's (nor glibc's) fault that this is the case.

musl is interesting for a variety of other reasons, but being more memory safe isn't really one of them.

Post reply on HN