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

491–500 of 639 posts

Re: Git's list of banned C functions

#491

Post by th3sly »

mjcohen wrote: post #447
nanagojo wrote: post #331

Earlier quoted context omitted.

> one of the best paying industries in this time and age Medicine is still better paid and better paid universally. Silicon valley is really the outlier here, most of Europe and the world programmers don't get paid that much in comparison.

Medicine also requires, after college, medical school and a residency - typically 6 to 9 years work. Programming requires none of this.

> Programming requires none of this.

But it requires you to refresh your knowledge constantly so from this point of view it's similar

Re: Git's list of banned C functions

#492

Post by edgyquant »

TheRealSteel wrote: post #151

I'm an idiot, I read the headline and thought these were banned from Git entirely. As in, you couldn't commit them to any repo using Git, at all. Thought that seemed a bit harsh. Turns out you just can't use them when you contribute code to the Git project. That makes sense, and seems reasonable.

Critiquing poor code practices is beyond the scope of git at this time

Re: Git's list of banned C functions

#493

Post by a1369209993 »

syncsynchalt wrote: post #157
Kaze404 wrote: post #106

Earlier quoted context omitted.

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?

There are actually very few _dangerous_ functions in C (gets is the only one that comes to mind). Others have massive caveats (strncpy) but still have their place. Others are just known to have certain gotchas (strcpy, strcat, sprintf). The reality of C is that if we deprecated every objectionable function in the stdlib we wouldn't have anything left.

> There are actually very few _dangerous_ functions in C

I think you mean there are very few functions that cannot possibly be used correctly (namely gets). Most C functions are dangerous - can lead to crashes and security vulnerabilties if used incorrectly - but that's just a expected consequence of using a language with no provisions for memory-safety.

> The reality of C is that if we deprecated every objectionable function in the stdlib we wouldn't have anything left.

Somewhat ironically, malloc is actually perfectly safe[0] - using the return value has some issues, but calling it is always[0] fine.

0: Assuming the OS-level memory allocator is sanely configured WRT overcommit, anyway.

Re: Git's list of banned C functions

#494

Post by 10x-dev »

WalterBright wrote: post #435
jchw wrote: post #45

Earlier quoted context omitted.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

Whenever I review C code, I first look at the string function uses. Almost always I'll find a bug. It's usually an off by one error dealing with the terminating 0. It's also always a tangled bit of code, and slow due to repeatedly running strlen. But strings in BASIC are so simple. They just work. I decided when designing D that it wouldn't be good unless string handling was as easy as in BASIC.

Mr. Bright, I just want to thank you for creating D.

It is by far my favorite language, because it is filled with elegant solutions to hard language problems.

As a perfectionist, there are very few things I would change about it. People rave about Rust these days, but I rave about D in return.

Just wanted to say thanks (and that I bought a D hoodie).

Re: Git's list of banned C functions

#495

Post by matheusmoreira »

guerrilla wrote: post #226
matheusmoreira wrote: post #206

Earlier quoted context omitted.

Yeah, because of NUL-terminated strings. They cause so many problems it's not even funny. Even something simple like computing the length of the string is a linear time operation that risks overflowing the buffer. People attempted to fix these problems by creating variations of those functions with added length parameters, thereby negating nearly all benefits of NUL-terminated strings. Why can't we just have some nic…

That would be nice. You hit on the other hell with C strings: modern encodings where wchar_t and mb* are useless and replacements essentially don't exist yet with char8_t, char32_t etc. Then there's the locale chaotic nonsense [1]. A new libc starting fresh would be nice. 1. https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

> A new libc starting fresh would be nice.

Agreed. I want to make something like this on top of Linux one day. I discarded the entire libc and started from scratch with freestanding C and nothing but the Linux system call interface. Turns out the Linux system call interface is so much nicer.

https://github.com/matheusmoreira/liblinux/blob/master/examp...

Re: Git's list of banned C functions

#497

Post by huhtenberg »

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.

All this stems from C strings being zero-terminated.

This in turn stems from the dedicated CPU support for working with zt strings that traces all the way back to PDP-11. So what C does here is exactly what it has always been doing - it provides a thin wrapper of the existing hardware functionality.

The variadic arguments are of the same nature - they basically allow for manual call stack parsing, again something that is a level down from the application code.

It's also easy to see how an API like sprintf and scanf came about - someone's just got tired of writing a bunch of boilerplate code to print a float with N decimals aligned to the left with a plus sign. So they threw together a function call "spec" (the format string), added a call stack parsing support (va_args) and - voila - a beautifully concise print/scan interface. It is a very clever construct, you've gotta give it that.

The flip side that it required people to pay close attention how they use it, which wasn't that bold of a requirement back then. But as time went on, the average skill of C programmers went down, their use of the language did too, so more and more people started to step on the same rakes.

So, here we are. Zero-terminated strings are forbidden and va_args calls are nothing short of the magic.

Re: Git's list of banned C functions

#498

Post by yetihehe »

commandlinefan wrote: post #149
jancsika wrote: post #95

I love seeing "strncpy" right after "strcpy." If someone wants some fun, try this: 1. Slurp up all the FOSS projects that extend back to 90s or early 2000s. 2. Filter by starting at earliest snapshot and finding occurrences of strcpy and friends who don't have the "n" in the middle. 3. For those occurrences, see which ones were "fixed" by changing them to strncpy and friends in a later commit somewhere. 4. See if you…

Ok, memcpy(dst, src, strlen(src)) it is then!

Yay for errors, it should be memcpy(dst, src, strlen(src)+1). Strlen doesn't count last 0. If your dst is not zeroed already you will have unterminated string.

Re: Git's list of banned C functions

#499

Post by signa11 »

lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

> dynamic allocation after application has started is banned -- any heap buffers and data structures must be allocated at the start of the application and after that any allocation is a compile time error,

how do ensure that?

Re: Git's list of banned C functions

#500

Post by klingon79 »

huhtenberg wrote: post #497
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.

All this stems from C strings being zero-terminated. This in turn stems from the dedicated CPU support for working with zt strings that traces all the way back to PDP-11. So what C does here is exactly what it has always been doing - it provides a thin wrapper of the existing hardware functionality. The variadic arguments are of the same nature - they basically allow for manual call stack parsing, again something tha…

I wonder if these headers were applied to the majority of C projects in, let’s say, all projects that were part of a Linux distribution- how much would fail to compile. My guess is: a lot.
Post reply on HN