Live data from Hacker News

Git's list of banned C functions

github.com

341–350 of 639 posts

Re: Git's list of banned C functions

#341
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…

Actually I experienced worse restrictions when I was at Siemens writing embedded. Expanding on your list, here are some extras: - ternary operator("?") was strictly forbidden. One had to use full "if () {..}else {..}" syntax with comments inside each branch even if the branch was empty - a dynamic array written in an abstract way, when used and implemented specifically for current project had to become a constant sta…

All of these except for the first two seem like good rules in general. Was the ban on the ternary operator just a style/readability thing?

Re: Git's list of banned C functions

#342

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

I don't really get the correlation between household income and programming experience in high school. Their parents can't afford a laptop? They can't afford an Internet connection? The kids don't have a good place to learn in their house? They don't have time? Is programming affected more than other subjects like math, English/grammar, science, etc?

The cost of computers has come down a ton, but it was a much bigger deal in the 90's and earlier. A lot of people didn't have computers at home. A decent x86 system (like a 486 with VGA etc) was at least $2500 or so. That's without any programming tools... compilers weren't free. When I meet fellow developers who didn't have computers growing up, I realize how privileged and lucky I was.

Re: Git's list of banned C functions

#343
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.) (…

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

My partner was on a doctoral training course at Oxford and they had to learn C over a few days; string manipulation is the hardest thing she remembers doing out of any medical science crash course they studied over 2 terms

Re: Git's list of banned C functions

#344
post #310

Earlier quoted context omitted.

>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object…

Strings have nothing to do with objects. You can write a string library, eg. [sds]( https://github.com/antirez/sds ). It's just not standard.

The challenge is not to write a string library, but to write a "nice" string library.

Let's say, something that's easier to use and doesn't have all the footguns of the char arrays.

The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.

Re: Git's list of banned C functions

#345

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…

I think 30-40 years ago it was perfectly appropriate to null-terminate strings. Every byte actually counted.

I remember thinking about setting the high bit to denote the end of string to save space.

Nowadays the binary for "hello world" might be as big as a whole operating system of the past.

(though honestly I can't recall the size of the OS on a boot floppy, but the original floppies were 160k)

Re: Git's list of banned C functions

#346
post #45

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.

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.) (…

> strings in C are actually hard,

Strings in C are more like a lie. You get a pointer to a character and the hope there is a null somewhere before you hit a memory protection wall. Or a buffer for something completely unrelated to your string.

And that's with ASCII, where a character fits inside a byte. Don't even think about UTF-8 or any other variable-length character representation.

In fairness, the moment you realize ASCII strings are a tiny subset of what a string can be, you also understand why strings are actually very complicated.

Re: Git's list of banned C functions

#347

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…

I would argue that C's fundamental mistake (well, more like limitation due to hardware of the time) was allowing arrays to decay to pointers; arrays hold valuable type information (the length!) that is lost once converted to a pointer. C99 came so very very close with VLAs. You can declare a function like: int main(int argc, char *argv[argc]) { ... } But C99 requires the compiler to discard the type annotations and t…

It wasn't a limitation due to hardware of the time. It was a deliberate choice due to C's ancestry as a derivative of B.

In B, thee was only one data type: machine word. The actual meaning was determined by the operators used on it. Thus, given x, (x + 1) would be integer addition, but *x would dereference it as a pointer (to another word). There was no need to distinguish between integer and pointer arithmetic, because their semantics was the same - pointers were not memory addresses of bytes, but of words, and thus (x + 1) would also mean "the next element after x", if x is actually a pointer.

When it came to arrays, B didn't have them as a type at all. It did have array declarations - but what they did was allocate the memory, and give you a variable of the usual word type pointing at that memory (which could be reassigned!). Thus, arrays "decayed" to pointers, but in a broader sense they did in C.

This all works fine on machine where everything is a word, and only words are addressable. But C needed to run on byte-addressable architectures, hence why it needed different types, and specifically pointer types to allow for pointer arithmetic - as something like (p + 1) needs to shift the address by more than 1 byte, depending on the type of p. But they still tried to preserve the original B behavior of being able to treat arrays as pointers seamlessly, hence the decay semantics.

BTW, this ancestry explains some other idiosyncracies of C. For example, the fact that array/pointer indexing operator can have its operands ordered either way - both a[42] and 42[a] are equally valid - is also straight from B. A more obvious example, the reason why C originally allowed you to omit variable types altogether, and assumed int in that case, is because int is basically the "word type" of B, and thus C code written in this manner very much resembles B. And then there's "auto" which was needed in B to declare locals because there was no type, but became redundant (and yet preserved) in C.

https://en.wikipedia.org/wiki/B_(programming_language)#Examp...

Re: Git's list of banned C functions

#348
post #138

Earlier quoted context omitted.

As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

In addition to the overhead from dyn alloc and the GC as someone else mentioned, there is also the size overhead that comes with every object in an OO language. The obj overhead for Java is JVM-dependent, but I believe it to be somewhere around 16 bytes.

A mostly unrelated stackoverflow post I found[0] states that an empty standard string in Java occupies 40 bytes due to the normal object overhead and overhead related to the internal byte array for the char storage. Obviously what you gain in return is convenience in programming as well as runtime-enforced safety from buffer overflows. Whether this is worth it depends on what you're doing.

In general, you're definitely absorbing overhead with any managed lang, although it need not be hidden. The specifics should be documented somewhere for whatever platform you're using, and most GCs are pretty tuneable nowadays.

[0] https://stackoverflow.com/questions/56827569/what-is-an-over...

Re: Git's list of banned C functions

#349

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

Having gone through the same experience, I can tell you that it isn't necessarily the case. More often than not, those who had some programming experience in some high-level language would often get discouraged with the difficulty and drop out. In the end, it was mostly those that didn't get discouraged and socialized with the other students that would remain in the end. I myself did not have any programming experien…

My experience with C courses with this structure of automatically validated home works not only filter "the weak" but also people with previous (especially C on Unix) experience, because nobody with any kind of practical Unix experience will write code that will pass these kinds of rigorous C-standard conformance and memory leaks checks, because for practical applications doing all that is actually not only unnecessary bud also detrimental to runtime efficiency.

Re: Git's list of banned C functions

#350

Earlier quoted context omitted.

I disagree. Commits messages exist for the very purpose of adding context to your code base. If you added for something that needs context, sure MAYBE add a comment, but I really pray that I'm going to find a few paragraphs disambiguating the problem within a git commit. If I'm _really_ lucky, maybe I find a PR number or Jira ticket reference as well. If you're truly clueless as to what could be substituted for these…

What if that code is refactored, moved around and changed so many times that it's nearly impossible to find the "documentation" for the line you're interested in. I mean sure you could spend a few hours going though commit messages, but wouldn't it be nice if there was a simple comment next to the code that gives the info right away? Also commits shouldn't be changed so if you want to improve the doc and provide more…

Or changed by an autoformatter.

Granted these concerns are probably less likely to apply to this particular file.

Perhaps they just felt that anyone contributing to git would already know why not to use those/what to use instead (but then there would be no need to ban them).

Post reply on HN