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

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

161–170 of 639 posts

Re: Git's list of banned C functions

#161

Post by Blikkentrekker »

munchbunny wrote: post #143
paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

The decision to make C strings null terminated with implied length instead of length + blob continues to trip us up, 30+ years later. There's a good reason the "safe" versions of those functions all take length parameters. But way back when this approach was chosen, I don't think the state of the art could fully predict this outcome. But also, "strings" and "time" are actually very complex concepts, and these functio…

> But also, "strings" and "time" are actually very complex concepts, and these functions operate on often outdated assumptions about those underlying abstractions.

Even in safer languages such as Rust, there are often quæstions as to why certain string operations are either impossible, or need to be quite complicated for a rather simple operation and are then met with responses such as “*Did you know that the length of a string can grow from a capitalization operation depending on locale settings of environment variables?

P.s.: In fact, I would argue that strings are not necessarily all that complicated, but simply that many assume that they are simpler than they are, and that code that handles them is thus written on such assumptions that the length of a string remain the same after capitalization, or that the result not be under influence of environment variables.

Re: Git's list of banned C functions

#162

Post by sudomakeup »

Kaze404 wrote: post #106
throwaway09223 wrote: post #37

Earlier quoted context omitted.

Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.

Why are these functions deprecated in favor of others but not removed? I know in Javascript this can happen so as to not break older websites, but in a compiled language this shouldn't be a problem right?

Why wouldn't it be an issue with a compiled language?

Its nearly the exact same reasoning as "we're not going to break older websites"

Re: Git's list of banned C functions

#163

Post by cma »

masklinn wrote: post #77
orf wrote: post #43

Earlier quoted context omitted.

Why make it harder, and why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made?

> Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.

> Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments.

What if they think of another reason why one of the same functions should be disabled?

Re: Git's list of banned C functions

#164

Post by hctaw »

ironmagma wrote: post #137
dangerbird2 wrote: post #63

Earlier quoted context omitted.

It's not really complacency: it's that the standard library is intentionally minimalistic to maintain portability and backwards compatibility. If you want sensible string handling, it's usually best to use a high level utility library like GLib( https://developer.gnome.org/glib/stable/ ) or Apache Portable Runtime( http://apr.apache.org/ ), or roll your own safe string type (preferably non-null terminating)

Why do you need backward compatibility with a compiled language? Other languages like Rust and JavaScript (even) avoid that with a pragma tag on the source.

Because not everything is recompiled from source. That's why stable ABIs need to exist.

Re: Git's list of banned C functions

#165

Post by xorcist »

chris_wot wrote: post #15
drfuchs wrote: post #6

It would be nice if the error messages generated would suggest replacement functions that they deem appropriate. I see that I'm not supposed to use gmtime, localtime, ctime, ctime_r, asctime, and asctime_r; but what do they think I should use?

The commits actually do give that info. Take for instance this commit: https://github.com/git/git/commit/c8af66ab8ad7cd78557f0f9f5e... It actually gives examples and a lengthy explanation and reasoning behind the ban.

Now that's what a good commit message looks like!

Re: Git's list of banned C functions

#166

Post by retrac »

munchbunny wrote: post #143
paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

The decision to make C strings null terminated with implied length instead of length + blob continues to trip us up, 30+ years later. There's a good reason the "safe" versions of those functions all take length parameters. But way back when this approach was chosen, I don't think the state of the art could fully predict this outcome. But also, "strings" and "time" are actually very complex concepts, and these functio…

For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.

Re: Git's list of banned C functions

#167

Post by ironmagma »

hctaw wrote: post #164
ironmagma wrote: post #137

Earlier quoted context omitted.

Why do you need backward compatibility with a compiled language? Other languages like Rust and JavaScript (even) avoid that with a pragma tag on the source.

Because not everything is recompiled from source. That's why stable ABIs need to exist.

Good point, thanks. Could the headers contain the pragmas?

Re: Git's list of banned C functions

#168

Post by chris_wot »

adrianmonk wrote: post #97
chris_wot wrote: post #71

Earlier quoted context omitted.

Because comments can be tedious and get out of sync with the repo. Why not check the git history? I wish more repos could be like this!

> Why not check the git history? Because that is effort every person who uses the file has to do over and over again, whereas maintaining the file is effort that has to be done once by one person.

It sounds like you want a manual. Personal preference I guess. The maintainers seem to have decided to keep it in the history. It's not like this was ever meant for anything other than git itself.

Re: Git's list of banned C functions

#169

Post by munchbunny »

fsociety wrote: post #116
xondono wrote: post #89

Earlier quoted context omitted.

Anything enforcing MISRA has essentially (almost) no way of allocating memory at runtime.

It’s funny, I worked exclusively with MISRA at the start of my career. Eventually I started a job at a FAANG and received quizzical comments on why I implemented a memory arena. The argument was to allocate memory freely and let it pool memory as necessary. Fair enough, it was simpler and fit the standard expectation of development. The issue is that if you talk with the allocator team they complain of not being able…

The lack of runtime allocations in game engine programming comes from a different motivation: allocations are expensive, garbage collections are expensive, cache coherency matters, and you're chucking around a lot of very similar looking objects, so... object pools!
Post reply on HN