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

41–50 of 329 posts

Re: Banned C standard library functions in Git source code

#41

Post by LukeShu »

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.

Re: Banned C standard library functions in Git source code

#42

Post by saagarjha »

calibas wrote: post #29
noname120 wrote: post #21

Why is there no brief explanations in this code why each function is banned?

I believe they're all vulnerable to overflows and easy to exploit. https://pointerless.wordpress.com/2012/02/26/strcpy-security...

> As many already know, strcpy(3) is a very unsafe function call in the C library (you should always use strncpy(3) unless you can be exactly certain about the number of bytes you’re going to copy beforehand).

strncpy pretends to be safe but fails to NULL-terminate and has other performance issues that generally lead me to believe it’s a security placebo. I would recommend using snprintf instead.

Re: Banned C standard library functions in Git source code

#43

Post by gus_massa »

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.

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.

Re: Banned C standard library functions in Git source code

#44

Post by LukeShu »

Koshkin wrote: post #40

> strcpy ... BANNED But they cannot ban while (* p++ = * q++); now can they.

It's not meant to be a substitute for humans reviewing patches. It's just meant to catch things new contributors are likely to try to use, and give them feedback on it before they send the patch to the mailing list.

Re: Banned C standard library functions in Git source code

#47

Post by LukeShu »

gus_massa wrote: post #43
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.

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.

Their "custom" procedure is the `git send-email` command, which has a lot more of a claim to be "standard" than GitHub's custom procedure.

Re: Banned C standard library functions in Git source code

#48

Post by saagarjha »

susam wrote: post #9
kbumsik wrote: post #6

Earlier quoted context omitted.

I'm not an expert in C, but then what's the issue with strncpy() or any "n" functions? It prevents overflow AFAIK. Also what is the alternative (memcpy?) and why?

strncpy() does not guarantee that the copied string would be terminated with a null byte ('\0'). For a call that looks like strncpy(dst, src, n), if there is no null byte in the first n bytes of src, the string copied to dst would also not contain a null byte. Here is an example code to demonstrate the problem: #include #include int main() { char a[] = "01234567"; strncpy(a, "foobar", 4); printf("%.8s\n", a); return…

Your macro refers to a twice; it might be better as a function.

Re: Banned C standard library functions in Git source code

#50

Post by noname120 »

noname120 wrote: post #21

Why is there no brief explanations in this code why each function is banned?

Just to make it clear. I'm aware of the fact that these functions have security implications. Nonetheless when such decisions are made, I believe it's important to explain them—at least briefly—directly in the code itself.
Post reply on HN