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

321–329 of 329 posts

Re: Banned C standard library functions in Git source code

#321

Post by LorenPechtel »

kijiki wrote: post #268
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

It is also the only way for an xlib program to survive losing its connection to the X server. xlib will let you register a callback to handle loss of connection with XSetIOErrorHandler, but unconditionally calls exit() after your callback returns. Which is extremely anti-social behavior for a library, but that is what it does. So the solution is to setjmp before each call to an X function that might notice the connec…

That's nuke-from-orbit level stupidity!

Re: Banned C standard library functions in Git source code

#322

Post by LorenPechtel »

dragonwriter wrote: post #319
cmroanirgo wrote: post #238

Earlier quoted context omitted.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

Depends which average it refers to any of the means, or the media, or the mode can be “average” (most typically, though, it means the arithmetic mean ), and it's only impossible in terms of the median.

Exactly. Anything where you have a main clump with a long tail will show this pattern--most samples will be better than the mean.

Re: Banned C standard library functions in Git source code

#323

Post by peff »

Cogito wrote: post #260
peff wrote: post #138

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

Peff, for the people asking in the thread, is there a place where correct alternatives are suggested or demonstrated? I know there are a few different places that talk about how to use git's internal machinery, but not sure if any are specific to these banned functions.

The commit messages that add them to banned.h discuss alternatives, though most of the explanations are Git-specific and assume you'll look elsewhere to figure out how to actually use those alternatives.

Re: Banned C standard library functions in Git source code

#324

Post by trasz »

jasonhansel wrote: post #147
stiff wrote: post #11

Looks 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

Nice. Is there a similar standalone C library for safe/sane string handling? (Please don't tell me to use C++.)

https://github.com/alexreg/libsbuf

Re: Banned C standard library functions in Git source code

#325

Post by tropo »

asveikau wrote: post #58
slovenlyrobot wrote: post #8

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

You can safely use gets on trusted input. For example, your program might create a pipe or socketpair to communicate between the processes that result from a call to fork. The stdout of one process feeds into the stdout of the other process.

Unless you have an insane gets implementation that writes the bytes backwards, you can also safely use it on untrusted input. Simply place a guard page at the end of the buffer. You can do the call from a forked child that you let die, taking notice of the problem in the parent. On systems without threading (because of locks in libc) you can do a longjmp to recover.

Re: Banned C standard library functions in Git source code

#326

Post by saagarjha »

toast0 wrote: post #252
saagarjha wrote: post #233

Earlier quoted context omitted.

My Chromebook just made me enable developer mode.

Developer mode lets you boot another OS, but leaves you open to accidentally wiping your drive if you hit the wrong button on boot. Replacing the firmware is a good idea, you do need to remove the write protect screw, but that really makes sense for some note of physical security.

Multiple wrong buttons in a specific sequence, at least on my Chromebook.

Re: Banned C standard library functions in Git source code

#327

Post by nybble41 »

anfilt wrote: post #249
kazinator wrote: post #78

If that header is ever accidentally included before any standard header, it's undefined behavior. :)

How? The preprocessor is ran before every thing else? It will overwrite the defintions in the header just like in the source file? You still would get a linking error. The only reason I couldn think is if the the stdlib headers also called undef for those functions. Moreover this is all during build not runtime.

According to C99, section 7.1.3:

    If the program declares or defines an identifier in a context in
    which it is reserved (other than as allowed by 7.1.4), or defines
    a reserved identifier as a macro name, the behavior is undefined.
It doesn't matter what the macro would expand to; simply defining the reserved identifier as a macro triggers undefined behavior. That doesn't mean it won't work, for some specific combination of standard headers, compiler, and program source code. It just isn't a strictly conforming program. A conforming implementation is allowed to flag this as an error, ignore the definition, or simply generate nonsense output.

Re: Banned C standard library functions in Git source code

#328

Post by Lerc »

valleyer wrote: post #280
Lerc wrote: post #191

Earlier quoted context omitted.

I had quite some fun playing around with it to obfuscate code. I did find that jumping to a different position in the same expression broke on a lot of compilers as soon as optimization was turned on. Here's a simple program to output a string with the characters in an unusual order. #include #include #define J(x,y) (longjmp(x,y),0) int main(int argc, char **argv) { jmp_buf j[011]; int x,X=0; signed char* i = " eehce…

This was super fun to decipher! 1. The first time through this giant ternary defines 9 different small subroutines. Each subroutine can consider the value of "x" to be their argument. X is used as an index into the jmp_buf (subroutine) array during setup, but after that it's always just equal to 8 2. Subroutines 0, 1, and 2 are special. Their argument is the index of another subroutine to jump to. They mutate the cha…

That's quite impressive work. It becomes a bit clearer if you think of the string as a tape. Then a big case statement with Left,Right,Mark seems rather Turing complete :-)

Re: Banned C standard library functions in Git source code

#329

Post by ncmncm »

bhk wrote: post #137
ncmncm wrote: post #112

Earlier quoted context omitted.

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

Does not apply. Nobody is born with C skills.

Competence can be measured objectively. Failure to understand array bounds is prima facie evidence of lack.

Post reply on HN