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

171–180 of 639 posts

Re: Git's list of banned C functions

#171

Post by slt2021 »

rodgerd wrote: post #74
SavantIdiot wrote: post #57

Earlier quoted context omitted.

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…

There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.

which language z/OS is written in?

Re: Git's list of banned C functions

#172

Post by Animats »

stefan_ wrote: post #70
cestith wrote: post #58

Earlier quoted context omitted.

Still, unless you're writing something that has to be very low-level all the way through, it's better to use a string-handling library than the stdlib tools for strings.

The first thing you do is not use any strings . You'll be amazed how much you can get done in languages that aren't so obsessively centered around stringified programming.

It was a design decision of QNX that the kernel never uses strings. Everything the kernel handles is fixed length, except messages, and messages go from one user process to another. The kernel does not allocate space for them. I think they go that right.

There's a QNX user process that's always present, called "proc", which handles pathnames and the "resource managers", programs which respond to path names. But that's in user space, and has all the tools of a user-space program.

Re: Git's list of banned C functions

#173

Post by badsectoracula »

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?

Removing anything breaks existing source code that has been tested to work. After all just because something may lead to issues it doesn't mean it will always lead to issues.

Also in many systems the C library is linked dynamically and shared among all programs so even though a program is compiled it still relies on the underlying system to provide the function.

Finally i'm certain that if a C standard removes something, it'll be treated as the equivalent to that standard not existing. C programmers are already a conservative bunch without such changes.

Re: Git's list of banned C functions

#174

Post by hctaw »

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…

Custom allocators are quite common, it's not an arcane convention. I think the rule of thumb is preallocate until it gets questionable in complexity, then write your custom allocator - and really it's only applicable to code with a real-time deadline (hard or soft). Otherwise the system allocator is going to be a lot smarter than yours once it leaves microbenchmarks.

Re: Git's list of banned C functions

#175

Post by JoeAltmaier »

retrac wrote: post #166
munchbunny wrote: post #143

Earlier quoted context omitted.

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.

Hey, languages used length,blob even when C was invented. HP Access BASIC used that kind.

It was a limitation, because they chose a byte length (to save space). So strings up to 255 characters only. It was decades before folks were comfortable with 32-bit length fields. And that still limited you to 4GB strings. In the bad old days, memory usage was king.

Re: Git's list of banned C functions

#176

Post by aendruk »

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.

I really wish tooling like this was more common:

https://github.com/eamodio/vscode-gitlens/tree/v11.2.1#curre... (screenshot)

> Current Line Blame: Adds an unobtrusive, customizable, and themable, blame annotation at the end of the current line

Re: Git's list of banned C functions

#177

Post by Animats »

Camillo wrote: post #130
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.

Many of the problems with C descend from a common root, the decision to use bare pointers (memory addresses) as the basic way to refer to strings, arrays etc. If they had used a {pointer, size} pair instead, it would have avoided all of these string problems, most buffer overflows, even the GTA Online loading problem that was on HN recently.

Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards.

Pascal, to save one byte, limited strings to length 255. Bad decision.

Re: Git's list of banned C functions

#178

Post by JoeAltmaier »

eschaton wrote: post #73
SavantIdiot wrote: post #57

Earlier quoted context omitted.

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…

This is a grossly inaccurate description of computing at the time of the rise of C. C was competing with Pascal/Modula, BLISS, PL/I, BCPL, and so on, not assembly on punched cards. The “C competing with assembly” meme was very specific to microcomputer game and operating system development, not more general microcomputer application development, and not to minicomputer or mainframe development.

Mainframes very quickly were outclassed by minicomputers. They could not respond quickly to technology changes as fast. C was indeed king for decades.

Re: Git's list of banned C functions

#179

Post by hctaw »

ironmagma wrote: post #167
hctaw wrote: post #164

Earlier quoted context omitted.

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

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

That assumes you have a header, which only exists at compile time for the developer. The running program knows nothing about it.

Re: Git's list of banned C functions

#180

Post by munchbunny »

Blikkentrekker wrote: post #161
munchbunny wrote: post #143

Earlier quoted context omitted.

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…

> locale settings of environment variables

Also known as "why does my code that parses floats fail in Turkey?"

Also also known as the discrepancy between a string's length-as-in-bytes, its length-as-in-code-points, and its length-as-in-how-humans-count-glyphs.

Strings are hard.

Edit to respond to your addendum:

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

I don't think I agree with that, though we may just be disagreeing on semantics. I think the big mistake many of us make is confusing two different abstractions for the same one. We've got this high level abstraction for "text" that includes issues like locale and encoding and several other things. And then we've got this low level abstraction for "text" that is just a blob of bytes. And we often mix the abstractions because it often turns out okay anyway. Otherwise we have to confront demons like "a UTF-8 string containing 10 characters can be anywhere between 10 and 40 bytes long".

Post reply on HN