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

221–230 of 329 posts

Re: Banned C standard library functions in Git source code

#221

Post by grogenaut »

rkagerer wrote: post #173
LukeShu wrote: post #41

Earlier quoted context omitted.

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"?

I believe the git project welcomes suggestions and discussion via the mailing list, and also accepts patches that like you suggested above.

Re: Banned C standard library functions in Git source code

#223

Post by philwelch »

noname120 wrote: post #75
asveikau wrote: post #37

Earlier quoted context omitted.

A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…

That's gatekeeping. If a junior developer starts working on this project they might bother a more senior developer who has better things to do with their time, or inline the definition of one of the functions out of frustration.

Git, like the Linux kernel, is essential, basic infrastructure that everybody uses and that needs to remain reliable. It's not a volunteer training project for dilettantes and neophytes. Gatekeeping is a deliberate part of how these projects are run and the results speak for themselves.

Re: Banned C standard library functions in Git source code

#224

Post by temac »

pjmlp wrote: post #170
dblock wrote: post #13

Windows programmers are familiar with StrSafe.h, https://en.wikipedia.org/wiki/Strsafe.h and https://github.com/dotnet/coreclr/blob/master/src/pal/inc/st... which go a lot further. Also found https://github.com/mubix/netview/blob/master/banned.h on Github with a better list.

Additionally we get to enjoy bounds checked arrays(std::...), and iterators on debug builds, with possibility to selectively enable them in release mode. While Windows by all means still has its security issues, the toolchain is much more security oriented than most FOSS alternatives thanks to the Windows XP wake up call. Android and ChromeOS are probably the mostly locked down alternatives on the FOSS space.

I don't know, you can use valgrind and fsanitize and ibstdc++ __gnu_debug:: containers or _LIBCPP_DEBUG under libc++.

Just know your tools...

Re: Banned C standard library functions in Git source code

#225

Post by philwelch »

MrStonedOne wrote: post #202
wincent wrote: post #91

Earlier quoted context omitted.

Because Git's own developers know to use git-blame, git-show, and write good commit messages. Comments are not the only place to store meta-info about why code is the way it is.

Git is open source, it doesn't have its own developers, every developer is "gits own developers". They really should make this more explicit.

Of course Git has its own developers, just as the Linux kernel does. There's no moral, technical, legal, or organizational obligation for the maintainers of any open source project to accept or solicit changes from randos.

Re: Banned C standard library functions in Git source code

#226

Post by philwelch »

MrStonedOne wrote: post #199
asveikau wrote: post #37

Earlier quoted context omitted.

A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…

I'm a c programmer, I'm reading this list, I don't know why they are there. You. Can. Not. Call. Yourself. Open. Source. If. You. Gatekeep. Your. Contributors.

Looks like they did.

Re: Banned C standard library functions in Git source code

#227

Post by f00zz »

Throw_Away_4384 wrote: post #105
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

> If it's used at all these days, it's used for exception handling. What about co-routines?

Yeah, I remember some green threads libraries based on longjmp/setjmp.

Re: Banned C standard library functions in Git source code

#228

Post by philwelch »

OJFord wrote: post #123
brianpgordon wrote: post #106

Earlier quoted context omitted.

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?

Yes, I've seen other instances of Microsoft/GitHub making substantial Git contributions: https://devblogs.microsoft.com/devops/supercharging-the-git-...

Microsoft seemed to have been adopting Git already, so it may be that acquiring Github was merely part of a broader Git strategy that Microsoft has adopted.

Re: Banned C standard library functions in Git source code

#229

Post by noname120 »

philwelch wrote: post #223
noname120 wrote: post #75

Earlier quoted context omitted.

That's gatekeeping. If a junior developer starts working on this project they might bother a more senior developer who has better things to do with their time, or inline the definition of one of the functions out of frustration.

Git, like the Linux kernel, is essential, basic infrastructure that everybody uses and that needs to remain reliable. It's not a volunteer training project for dilettantes and neophytes. Gatekeeping is a deliberate part of how these projects are run and the results speak for themselves.

Makes sense, thanks for taking the time to answer.

Re: Banned C standard library functions in Git source code

#230

Post by [deleted] »

dezgeg wrote: post #213
jandrese wrote: post #120

Earlier quoted context omitted.

But still not safe, thanks to the return value. Imagine the case where you are using strlcpy because you can't be sure if the source buffer is properly null terminated.

If your buffer isn't a NUL-terminated, then don't call a function that is only defined for NUL-terminated buffers. It's as simple as that. I'm baffled by how some people claim strlcpy() is 'broken' or 'not safe' because it doesn't handle non-NUL-terminated inputs; the exact same thing applies to just about any function in the C standard library that takes strings as input. Are functions like strchr(), fopen(), printf…

[deleted]
Post reply on HN