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

131–140 of 329 posts

Re: Banned C standard library functions in Git source code

#131

Post by r3trohack3r »

segfaultbuserr wrote: post #72
adamnemecek wrote: post #27

Earlier quoted context omitted.

Like essentially all C programs.

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 in the ecosystem. I just see those implementations trapped inside code bases that don’t export them in a consumable way for other projects...

Personally I love writing C but rarely do because dependency management makes innovation in those code bases so time consuming for me.

Re: Banned C standard library functions in Git source code

#132

Post by johannes1234321 »

crankylinuxuser wrote: post #80
slovenlyrobot wrote: post #56

Earlier quoted context omitted.

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

Goto requires the fail block to be in the same frame. It can be a working error strategy for failing critical errors in such a way from a failing module. You have to be aware that lots of stuff is prone to leak (which can be avoided by i.e. using some memory arena) and locks/mutexes/... might be in unclear state, so code has to be aware of that.

Re: Banned C standard library functions in Git source code

#133

Post by IshKebab »

slovenlyrobot wrote: post #56
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

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

You're in the 1% though right?

Funny way of saying "too error-prone for anyone sane to consider using".

Re: Banned C standard library functions in Git source code

#134

Post by zsrxx »

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 .

I haven't looked much so I can't comment on the quality of the library but that hairdo is glorious. Props to Salvatore!

Re: Banned C standard library functions in Git source code

#135

Post by bhk »

asveikau wrote: post #129
derefr wrote: post #116

Earlier quoted context omitted.

> 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 sta…

Ah, yes. What I described wasn't reentry. A reentrant function using strtok could exhibit this problem, but it applies more widely than that.

Re: Banned C standard library functions in Git source code

#136

Post by saagarjha »

chris_wot wrote: post #92
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've always wondered why goto is actually considered harmful. I really should read the original paper by Djikstra...

It encourages spaghetti code.

Re: Banned C standard library functions in Git source code

#137

Post by bhk »

ncmncm wrote: post #112
bhk wrote: post #90

Earlier quoted context omitted.

If every C programmer knew, then there would be no need to ban them

Not knowing defines you as not a C programmer. That doesn't stop many people from trying to code C anyway... I have seen strtok used, even though it takes more code to use it correctly than not use it. strlcpy is like that, too. Of course, what happens is nobody uses them correctly.

https://en.m.wikipedia.org/wiki/No_true_Scotsman

Re: Banned C standard library functions in Git source code

#138

Post by peff »

I see a lot of comments to the effect of "shouldn't XYZ also be banned". The answer is that we're not necessarily trying to be exhaustive. The point is to flag common errors before we even hit review, so we add new functions mostly when somebody tries to misuse them. I don't recall anybody trying to abuse longjmp() in Git's codebase yet (and no, that's not a challenge).

Re: Banned C standard library functions in Git source code

#139

Post by peff »

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

Re: Banned C standard library functions in Git source code

#140

Post by saagarjha »

jpjuni0r wrote: post #114
slovenlyrobot wrote: post #8

That's a surprisingly small list, missing e.g. sscanf / gets / strtok / all the other "usual suspects" at least

I'm curious how sscanf is considered bad?

scanf(“%s”, …) can cause a buffer overflow.
Post reply on HN