Git's list of banned C functions | Hacker News Reader

Git's list of banned C functions

github.com

876 pointsmuds613 comments

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

(~~Technically~~ Optionally, C11 has strcpy_s and strcat_s which fail explicitly on truncation. So if C11 is acceptable for you, that might be the a reasonable option, provided you always handle the failure case. Apparently, though, it is not usually implemented outside of Microsoft CRT.)

edit: Updated notes regarding C11.

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.

In the case of C, it's a design decision Denis Ritchie made that came down to the particular instruction set of PDP-11, that could efficiently process zero terminated strings.

So a severely memory limited architecture of the 70s led to blending of data with control - which is never a safe idea, see naked SQL. We now perpetuate this madness of nul-terminated strings on architectures that have 4 to 6 orders of magnitude more memory than the original PDP-11.

It's also highly inefficient, because a the length of string is a fundamental property that must me recomputed frequently if not cached.

Bottom line, unless you work on non-security sensitive embedded systems like microwave ovens or mice, there is absolutely no place for nul-terminated strings in today's computing.

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

Hello Walter! All things considered, you are probably the best person to ask for tips on string handling in C.

Would you might sharing the things that you look for, from the obvious to the subtle? I would love to see some rejected push requests if possible. If I were writing C under your direction, what would you drill into me?

Thank you, it is an honour to address you here.

IIRC, in the early days of the Commodore PET, it used a method of keeping track of strings that was fine in an 8k machine but was too slow in a 32k machine. They had to make a change that avoided quadratic time on the larger machine. So string handling in BASIC wasn't always that simple.

I’m not sure if it was the original purpose of C, or of it’s what made C popular, but compared to BASIC, processing strings in C was much faster.

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.

> I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time.

But if you keep up the good work you will one day go from

  extern void *lecturer;

  static const lecturer;

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them). Two days, over the weekend, to do a small project to validate this.

Then on the monday, it was makefiles if i remember correctly, then open(), read(), close() and write(). Then linking (and new libc functions, like strcat) . A day to consolidate everything, including bash and git (a new small project every hour for 24 hours, you could of course wait until the end of the day to execute each of them). And then some recursivity and the 8 queen problem. Then a small weekend project, a sudoku solver (the hard part was to work with people you never met before tbh).

The 3rd week was more of the same: basic struct/enums exercises, then linked list the next day, maybe static and other keyword in-between. I used the Btree day to understand how linked list worked (and understand how did pointer incrementation and casting really work), and i don't remember the last day (i was probably still on linked lists). Then a big, 5-day project, and either you're in, or you're out.

I assure you, strings were not the hardest part. Not having any leaks was.

Most of the C I wrote was while in college. I think understanding the question, "why are strings in C hard?" is a good gateway to understanding how programming languages and memory work generally. I agree with you though that teaching C as introductory is probably not the best — our "Programming in C" course was taken in sophomore year.

I wouldn't want to use it my day job, but I'm glad that it was taught in university just to give the impression that string manipulation is not quite as straightforward as it's made to appear in other languages.

The early days of Swift also reminded me of this problem – strings get even more challenging when you begin to deal with unicode characters, etc.

I am seeing Python becoming the go-to language for many academics because it's easy to hack something together that somehow works.

Unfortunately most of those developers don't care much about efficiency and Python is out of the box inefficient compared to other high-level languages like Java [1] or C#. OO Java courses circulating in academia lack modern functional, and to be frank educational, concepts and must to be refreshed first.

I personally would recommend to start with Java and Maven because it's still faster than C# [2], open source, and has a proven track record in regards of stability and backwards compatibility. Plus quickly introduce Spring Framework and Lombok to reduce boiler plate code.

For advanced systems programming I suggest looking into Rust instead of C/C++.

And last but not least the use of IDE's should be encouraged and properly introduced, so aspiring developers are not overwhelmed by them and learn how to use them properly (e.g. refactoring, linting, dead code detection, ...). I recommend Eclipse with Darkest Theme DevStyle Plugin [3] for a modern look.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[3] https://marketplace.eclipse.org/content/darkest-dark-theme-d...

I've studied IT in early 00s in Poland, the course was a little outdated, but it had some advantages.

We've started from 0 with no assumption of any computer knowledge and first 2 years most courses were using Delphi (console only, no GUI stuff, basically it could just as well have been Turbo Pascal, some Linux enthusiasts used FPC instead of Delphi and it worked).

We all complained that we want C++ then, but I've learnt to appreciate Pascal later. After first few months we've known every nook and cranny and there was very little corner cases and gotchas. So basically we focused on algorithms and not on avoiding the traps language set for us.

Most people had no programming experience and after a few weeks they wrote correct programs no problem.

I doubt this would happen if we started with C++ as most people wanted, and I think it's better than Python as a starting language because it teaches about static typing and difference between compile- and run-time.

Sadly it's a dead language now.

> Technically C11 has strcpy_s and strcat_s

"Theoretically" is the word you're looking for: they're part of the optional Annex K so technically you can't rely on them being available in a portable program.

And they're basically not implemented by anyone but microsoft (which created them and lobbied for their inclusion).

The issue is pretending that C even has strings as a semantic concept. It just doesn't. C has sugar to obtain a contiguous block of memory storing a set number of bytes and to initialize them with values you can understand as the string you want. Then you are passing a memory address around and hoping the magic value byte is where it should be.

C is semantically so poor, I find it hard to understand why people use it for new projects today. C++ is over complicated but at least you can find a good subset of it.

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

What I don’t understand is why C programmers use the built in strings. It’s like rolling your own sorting algorithm every time you need it. Surely someone could write a better string library in C that hides the complexity. The real problem is that C programmers are apparently allergic to using other people’s code.

I'm partial to https://github.com/antirez/sds these days

strcpy is a coding challenge where I work for interviews. I typically ask them to write it as the standard version and ask them why they might not want to use it to see if they are aware of the risks. After that I ask them to modify the code to be buffer safe. And for those claiming C++ knowledge ask them to make it work for wchar_t as well to see if they can write a template. Some people really struggle with this.

If only C had followed the Pascal way to have the size with a string - so much human suffering could have been avoided!

> ~~Technically~~ Optionally, C11 has strcpy_s and strcat_s which fail explicitly on truncation. So if C11 is acceptable for you, that might be the a reasonable option, provided you always handle the failure case.

One of the big problems with C programmers is they often neglect to check for and handle those failure cases. Did you know that printf() can fail, and has a return value that you can check for error? (Not you, personally, but the "HN reader" you) Do you check for this error in your code? Many of the string functions will return special values on error, but I frequently see code that never checks. Unfortunately, there isn't a great way to audit your code for ignored return values with the compiler, as far as I know. GCC has -Wunused-result, but it only outputs a warning if the offending function is attributed with "warn_unused_result".

I'm not a huge fan of using return values for error checking, but we have the C library that we have.

Truncation, even if it is wrong in an application logic sense, is strictly superior to UB (and in practice, buffer overruns, which can be exploitable). That's the main benefit of strlcpy/strlcat. It is certainly possible to construct a security bug due through truncation! But it is much more common to have security bugs from uncontrolled buffer overruns.

Yeah. I just avoid str manipulations in general in C and when I have to, fuzz it ... (but still, the perf cliff is definitely new to learn in the past few days).

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 functions operate on often outdated assumptions about those underlying abstractions.

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 treat the declaration as equivalent to:

  int main(int argc, char **argv) { ... }

Imagine a world where the C string functions were declared as:

  char *strndup(s, n)
    const char *s[n];
    size_t n;
  {
    /* now we can do sizeof(s) and bounds checking! */
  }

(You'd have to use K&R style declarations to get around the fact that the pointer argument comes before the length argument, alas.)

Edit: and then C11 made VLA support optional, since the feature didn't get used much, because the feature was only half-baked to begin with... sigh.

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

What you want works, you just used the wrong syntax:

    #include <stdio.h>
    
    void foo(int len, const char (*str)[len]){
        printf("%zu\n", sizeof(*str));
        printf("%.*s", len, *str);
    }
    
    int main(void){
        // note: not nul-terminated
        const char text[] = {'h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd', '!', '\n'};
        // prints 13, then 'hello world!'
        foo(sizeof(text), &text);
        return 0;
    }

See WalterBright's 2009 blog post, C’s Biggest Mistake, about exactly this.

https://digitalmars.com/articles/C-biggest-mistake.html

It's because to get that to actually work you need dependent types. Which—it's not gonna happen.

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.

The prefix approach turns the neat "strings are just character arrays are just pointers" pattern into something a lot more clunky, because now you've got this really basic data type that is actually a struct and now you have to have an opinion on how wide the length value is and short strings get a lot of memory overhead in just lengths, and so on.

In hindsight, I think the complexity is worth the safety, but I could see why it felt more elegant to use null-terminated strings at the time.

Pascal strings are not inherently memory safe:

   cat_pascal_strings(pascalstr *uninited_memory,
                      pascalstr *left,
                      pascalstr *right);

how big is uninited_memory? Can left and right fit into it?

You need to design language constructs around Pascal srings to make them actually safe. Such as, oh, make it impossible to have an uninitialized such object. The object has o know both its allocation size and the actual size of the string stored in it.

What is unsafe is constructing new objects in an anonymous block of memory that knows nothing about its size.

C programs run aground there not just with strings!

   struct foo *ptr = malloc(sizeof ptr);  // should be sizeof *ptr!!

   if (ptr) {
      ptr->name = name;
      ptr->frobosity = fr;

Oops! The wrong size of allocated only the size of a pointer: 4 or 8 bytes, typically nowadays, but the structure is 48 bytes wide.

"struct foo" itself isn't inferior to a Pascal RECORD; the problem is coming from the wild and loose allocation side of things.

Working with strings in Pascal is relatively safe, but painfully limiting. It's a dead end. You can't build anything on top of it. Can you imagine trying to make a run-time for a high level language in Pascal? You need to be in the driver's seat regarding how strings work.

On platforms with limited register sets, keeping length around burns a register that could be used for something else. From the mindset of assembler programmers wanting a high level language that suits them, a sentinel that doesn't consume extra machine resources was preferable. Not to mention all the precious RAM those multi-byte lengths squander.

Strings as they existed in standard Pascal were extremely limited in how you could work with them, since it didn't have true dynamic arrays.

Strings as implemented in e.g. Borland Pascal were better. But then, the length-prefixed implementation had its own downsides. For example, it had to decide how many bits to use for length. 16-bit Pascal would generally use a single byte, and in BP at least, you could even access it as a character via S[0]. Thus, strings were limited to 256 bytes max - and because this was baked into the ABI, it wasn't something that could be easily changed later.

Hence when Delphi decided to fix it, they basically had to introduce a whole new string type, leaving the old one as is. And then they added a bunch of compiler switches so that "string" could be an alias for the new type or the old, as needed in that particular code file.

(Many of) The trade-offs were known to Richie et al; writing in 1993:

> None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled `*e'. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator.

[…]

> C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user. Nevertheless, C's approach to strings works well.

* https://www.bell-labs.com/usr/dmr/www/chist.html

He mentions Algol 68 and Pascal [Jensen 74].

Oh Pascal, why couldn't we have had you instead.

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

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

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)

Just a surreal reminder that 30 years ago was 1991. By that time it already didn't make sense to null terminate strings (except perhaps on embedded platforms).

30+ years -> 50+ years

Funny mind thing to forget to increment counters each year.

C89 was 32 years ago, so I think saying 30+ years is fair.

The reason that the safe functions take length parameters is that they produce a new object in uninitialized memory, a pointer to which is specified by the caller.

It has nothing to do with null termination.

And that uninitialized memory is not self-describing in any way in the C language. Which is that way in machine language also.

This is a problem you have to bootstrap yourself somehow if you are to have any higher level language.

The machine just gives you a way to carve out blocks of memory that don't know their own type or size. C doesn't improve on that, but it is not the root cause of the situation. Without C, you still have to somehow go from that chaos to order.

Copying two null terminated strings into an existing null-terminated string can be perfectly safe without any size parameters.

   void replace_str(char *dest_str, const char *src_left, const char *src_right);

If dest_str is a string of 17 characters, we know we have 18 bytes in which to catenate src_left and src_right.

This is not very useful though.

Now what might be a bit more useful would be if dest_str had two sizes: the length of string currently stored in it, and the size of the underlying storage. This particular operation would ignore the former, and use the latter. It could replace a string of three characters with a 27 character one.

Null terminated strings are remnants of an era when computers had little memory available. So, at the time it seemed smart to discard the length field and use a single byte-sized terminator (null). If you are writing an operating system for a machine with little memory to spare, this seems like a good decision. Of course things are very different now when memory is not a problem and the goal is safety.

> If you are writing an operating system for a machine with little memory to spare, this seems like a good decision.

Also registers! Especially in syscall interface, consider eg:

  int renameat(int olddirfd,char* oldpath,int newdirfd,char* newpath); /* first example I found that had 2 paths */

If you have registers edx,ecx,esi,edi,ebx available, nul-terminated strings make this fit into:

  edx olddirfd,ecx oldpath,
  esi newdirfd,edi newpath

If you need separate length fields, there simply aren't enough registers:

  edx olddirfd,ecx oldpath.ptr,esi oldpath.len,
  edi newdirfd,ebx newpath.ptr,??? newpath.len

> memory is not a problem and the goal is safety.

People keep repeating this. What about embedded systems? For instance, I have to know how an object is structured and how is allocated, exactly and without surprises. The behavior has to be predictable and as simple and fast as possible. You can (likely) achieve that with C.

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

Together with parent comment, this is exactly how I feel every time I use something that is not C (I do mostly embedded). Like: ok, I can use a slice here, but what is a slice? what thing is it doing that I don't know? where's the catch? how does it look like in memory? is it calling a function when I access it? is it being copied or referenced?. And so on...

Basically every (non-C) string implementation in existence has to do dynamic memory allocation under the hood, which is hidden from the programmer. That’s the overhead.

> When I program in C I feel like I know a lot better what the generated instructions will be.

If you don't know about the Compiler Explorer, definitely check it out: https://godbolt.org

There certainly is --- it's very easy to make accidentally quadratic (or worse) algorithms in languages where data structures automatically resize themselves to their contents.

To be honest, with today’s compilers you can’t be all that sure about the generated code. They do some insane tricks under the hood to make naively written code perform good. As per a “famous” blog post, C is a high level language.

Yeah, every time I decide to play with C for nostalgia's sake, I immediately get hung up on just how painful everything is, especially strings.

I still love C, but I'd do my best not to have to write anything serious with it again.

I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had.

Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up.

Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures.

Now given the massive amount of existing C out there from the time of such architectures, you either have to move the API and language on to make it incompatible with existing code, or support the old baggage. The language has kept compatibility, and in this case, the github peeps have deprecated APIs using macros, so it's a reasonable approach.

An alternative approach would be to move the language on, but by it's nature it won't be compatible with C, so you give it a new name. You call it things like go, or rust, or swift. These are all C with the dangerous bits removed. It'll be interesting in 40 years time to see if people are having the same conversation about these languages - 'OMG, how did people write stuff in rust? It can't cope with [insert feature of distributed quantum computing]. It's really scary'

I wouldn't say that Go is an alternative approach. I mean, what's the difference between Go and Java AOT with Graal? But Rust is truly an alternative to C/C++.

In many ways Go is the safer more productive language for C lovers. There are only a couple major differences between the two languages so I think that it is one of the easier places to convince C lovers to move to. I have met a number of strong C proponents and they all seem to be relatively OK with Go, especially compared to C++, Rust and Python.

The major differences in my head are:

- Garbage Collection

- Interfaces

There are some other more minor things like defer and the built-in generic types but many C programmers already had macros to implement similar things.

So sure, Go doesn't solve all of the problem spaces that C does. But if you are in a problem space where you don't need see (or another low-level systems language) Go may be a middle ground to move C programmers to.

> what's the difference between Go and Java AOT with Graal?

The thing that C/Go authors brought in straight from the seventies: utter garbage naming of identifiers.

But then again, the name of the language itself should be warning enough.

This is git, not github.

A better way of looking at it is that functions which expose very simple operations were among the first ones to be placed into the standard library -- and consequentially are the least well thought out.

This is a lot like how in JavaScript you have footguns like the with statement or in Python 2 where you have Unicode issues, etc. I am sure we could definitely a new C standard that excludes these functions as obsolete, but the linked header file is a pretty sensible interim solution. C is an old language and it’s kind of amazing that code written 30 years ago can still by and large be compiled by a modern compiler. Ever try to run 3 year old React projects using today’s React? :)

> in JavaScript you have footguns like the with statement

I've been coding in JS on a daily basis for more than 10 years and today I learned there is a `with` statement in JS.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Edit: well, seems like it's been deprecated/forbidden since ES5 (2009), so it makes sense I've never seen it.

An old grad school connection of mine wrote a formal semantics for ES5 and couldn't explain what "with" did in words.

And me around 20 years - also never even heard of the `with` statement! I think to qualify as a footgun, people actually need to be using it in the real world.

Was also popular in ActionScript, the JS cousin that powered dynamic Flash content:

    with (myShape.graphics) {
      beginPath();
      setFill(0xFF0000);
      moveTo(6, 9);
      // ...
    }

It amuses me that HN hates JS so much, that even a topic about problems with C turns into a JS-bashing thread.

Also, I just want to remind you that JS isn't just React. There are plenty of libraries written in C that introduce breaking changes over the course of 3 years. Nothing will stop people from finding ways to complain about JS though, I know. The hate-boner is very real.

I've been a long-time Javascript hater. Probably didn't help that I started out 20 years ago, and dealing with cross-browser support was a big issue. And of course, let's so no more about Internet Explorer shudder. And then NPM - a direct result of JavaScript's anaemic standard library.

Anyway, things have changed a lot, and I recently worked on my first ever web app with native ES6 - no transpiling to ES5! It was... not nearly as bad as it used to be! Modules are a thing, and the language has evolved with things like async/await, evolved for the better, I think. The standard library is still horribly anaemic though - the number of "helper" functions needed is ridiculous.

But still, I would no longer classify myself as a hater. Progress at last :)

I appreciate Javascript's LISPy qualities, but it has an inordinate number of footguns and a relative lack of standard, stable libraries. Coming from languages like Java and Erlang that are relatively scrupulous about such things is a bit jarring.

I do like Typescript though, as it adds some really nice ergonomics.

I think in most cases it's probably not hate but a deep, deep love.

I think most people on HN like Javascript, or at least its idea? I mean, its a very C-like functionnal language, especially since ES6 put Js on the right road (for me at least)?

Because individual libraries choosing to change quickly is comparable to language stability how? The relevant comparison would be "run a 3y old react app (or a 20 year old website using JS) in a modern browser or interpreter"

Yes, and it would still run fine I guess. I think only eval() changed over time. APIs and so on are still the same except for some Netscape stuff.

Insofar as stdlib for C is a library, I think it’s not the worst comparison.

The string stuff is kind of the original sin, but to be honest almost all programming environments have massive footguns when it comes to times/dates. Python's datetime story is _extremely_ painful to deal with. Try doing .... I dunno, anything apart from getting the current time and doing an ISO format of a Javascript Date object.

I think stuff has kinda gotten better, but while Unicode had emoji to kinda save the day, dates never had this moment and we're still suffering through major messes on a daily basis because of it.

Python's dates are very unlikely to cause quadratic or exponential performance dips, segfaults, or remote code execution vulnerabilities. (And JS now has Date#toISOString, since ES5.)

C's string manipulation functions are a regular source of the worst vulnerabilities in software.

Even if they're in the same category of legacy cruft, they're not even remotely in the same magnitude of consequences.

I think you misread my message, I was saying that "time stuff is messed up everywhere", not "python's time stuff is like C's string stuff". The C string stuff is a mess.

I was also saying that JS dates _can_ generate ISOStrings. But good luck doing any serious manipulation without issues. Hell, there isn't even a `strftime` equivalent for JS dates! And so much stuff ends up going through locales that you can't rely on it for machine transformations.

I would be careful about ascribing the quadratic perf discussion to be a C thing though.... I find loads of "accidentally quadratic" stuff in loads of languages all the time. People are really bad about this (lots of confusion between "this is built-in to the data structure" and "this is cheap").

Anyways, yeah. Strings are uniquely awful. Other C APIs suffer from issues, but I find those issues are on par with other language thing. Granted, it's sometimes _because of C_ that other languages suffer from the issues (by relying on C layers for the logic).

Yeah, there is a culture of complacency in C probably owing to the enormous historical baggage of legacy code that has to be supported and the blurred line between stdlib and system call.

I disagree completely. Devs who use C are the least complacent about security in my experience. The problems are from previous eras before they knew about many of these things. A ton of people in modern languages couldn't name a single dangerous function, though they do exist in every language. You'd be amazed at how many race condition vulns result from TOCTOU errors just in authentication, or checking for the existence of a file before opening it, etc.

It's absolutely true that decades ago the C community was complacent, but it's not true now. Source: I taught secure coding in C/C++ in the 00s.

What you said. Nobody is complacent. Anyone who thinks the Linux or OpenBSD (etc.) kernel developers take the lazy way out is talking about a thing they know little about. I do think better languages than C exist and maybe could even be used as a basis for new systems. But I have yet to see a mature OS that’s as secure and as performant as these. Closest might be the chips I’ve seen that have an embedded Java byte code interpreter.

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)

No, if you want sensible string handling, the sane choice is usually to choose to use a language that is not C. Not always, but definitely usually.

there's nothing inherently unportable about strings though.

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.

c standard library doesn't really relate directly to system calls (at least in modern os'es). In particular, the stdio.h functions are buffered by default, while their system call analogues are not. For unixes, system call wrappers are typically found in <unistd.h>, not the "official" c standard library

I mean on Linux you're not encumbered by this because the syscall api is stable but in practice most GNU/Linux distros assume glibc. You can't correctly resolve a hostname on Linux without farming out to glibc -- hell even the kernel punts to userspace for dns names but you can technically ignore it if you want.

On BSDs and macOS you're always SOL because the syscall api isn't stable and only the C wrappers are.

While it's true that there are a lot of unsafe functions in C, it's not really a mistake. C is a fundamentally unforgiving language. You just have to accept the fact you're driving a naked supercar with no seatbelts.

It's easy to survive: just don't crash. :)

And, functions aside, it's trivial to write a C program that bombs out without calling any functions at all, safe or otherwise.

It's a language from a different era, for sure. Back then no one had the computing power to build Rust. And remember that before C, they were writing Unix in assembly language. So sprintf() was a big step up!

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 nice structures instead?

  struct memory {
      size_t size;
      unsigned char *address;
  };

  enum text_encoding { TEXT_ENCODING_UTF8, /* ... */ };

  struct text {
      enum text_encoding encoding;
      struct memory bytes;
  };

All I/O functions should use structures like these. This alone would probably prevent an incredible amount of problems. Every high-level language implements strings like this under the hood. Only reason C can't do it is the enormous amount of legacy code already in existence...

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

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

To all the people popping off about how great other languages are, tell me: when will we see the Unreal Engine written in Python, or Pascal, or Algol, or Rust, or Go... the next big step is WebASM (or .cu), and that's way more footbullet-y than C. And what is the native language all of your sub-30 year old interpreted languages were written in? Thank you!

Yeah there are footguns in every language. But this is not a boolean question about the presence of footguns, this is about how much one has to know to be able to handle a language safely.

I know C/C#/Python/Rust/Javascript.

After a decade of using C I am still not totally sure if I didn't dangle a pointer somwhere in precisely the wrong way to create havoc. And yeah, that means I have to get better, etc. But that is not the point. The point is, that even with a lot of experience in the language you can still easily shoot yourself into the foot and don't even notice it.

Meanwhile after a month of using Rust I felt confident that I didn't shoot myself in the foot, because I know what the compilers e.g. ownership guarantuees. While in C shooting myself into the foot happen quite often in Rust I would have to specifically find a way to shoot myself into the foot without the compiler yelling at me, and quite frankly I havent found such a way yet.

Javascript is odd, because the typesystem has quite a few footguns in it. This is why such things like Elm or Typescript exist: to avoid these footguns.

I don't want to take away from the accomplishments of C, and I still like the language, but to claim it is equally likely in all languages to shoot yourself into the foot is not true.

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.

Recall that during the rise of C, people were writing machine code on punch cards.

Or Fortran, Algol, Lisp, Cobol, Basic, Pascal, ...

My favorite assembly foot gun was a guy I worked with had a cute routine. You had a call to the routine, followed by a null terminated string after that. The routine would spit the string to the terminal. And then return to the location after the string.

He had some bug where in one place it returned to the start of the string, executed it, and kept going. The end result just happened to be a nop. Had been like that in production for a couple of years.

And when you fix it, everything breaks.

Consider the fact that Simula-67, which predated C by 3 years, had classes and objects very similar to what Java offers (and then some - e.g. coroutines), and a built-in string processing library that used object-oriented syntax.

The reason why C won had little to do with its advantages as a language over the competitors. It just happened to be the systems language for Unix, which was the winner in the early OS wars on microcomputers (for unrelated reasons). Once it became so established, there was a positive feedback loop: you would write portable code in C, because you knew that it was the fastest language that most platforms out there would support. And then any new platform would offer a C compiler, because they wanted to be able to run all the existing C code out there. And so, here were are.

Your edit really isn't helping your case.

Those of us who have always known about less dangerous 'system' languages (Pascal probably being the most popular) lament the fact that so much code got written in C instead.

It wasn't inevitable. It was preventable! It just didn't happen that way for reasons which are largely historical.

I don't work for the Rust Evangelism Strike Force, my main project is written in (as little) C (as possible), but I beg anyone who has a choice: use something else! Rust is... fine, Zig is promising. Ada still works!

Writing out the set {Python, Pascal, Algol, Rust, Go} tempts me to say uncharitable things about your understanding of the profession, but I accept you were just being snarky so I'll just gesture in the direction of how $redacted that is.

> when will we see the Unreal Engine written in...

Why would a huge C++ (not C, btw) codebase with roots going back to the 90s be rewritten in any other language?

And in fact how is the language Unreal Engine written in relevant to C having footguns?

Not that I dont believe there are any, but I'd love to hear your perspective...

Go (golang)

defer having function scope instead of, well, scope scope.

Using defer to unlock locks can lead to some fun deadlocks if you don't realize the issue with the scope, and it's completely unintuitive to someone with experience with other implementations of similar concepts.

channel programming and the races caused by closing channels. channels seem nice and easy until they don’t.

the whole var/:=/= assignment combined with the error handling style and the shorthand is another one

Well, shit. Got me there.

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

citation needed

I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

but there's a significant albeit rarely seen or sought for ecosystem for managing software on mainframes the source to which is long lost and the authors deceased and the the machine code is what you have to work with. you can't describe the work as being attractive, but the tooling which exists is first class and has been keeping the world turning safely for a good half century I'd say in reality...

Nearly everything around you runs code that was written in C, and absolutely nothing you can actually see runs COBOL code.

which language z/OS is written in?

Just because I want to know people opinion's (+they may be more than happy to shit on C#:)

But please, nothing about using unsafe.

gmtime is just not thread-safe that's all, since it returns a static structure; gmtime_r is not banned.

Thanks, I am now a decade out of the C game and I was wracking my brain on what the problem with gmtime would be. My best guess was dodgy is_dst portability /shrug

Yeah, found this which explained it for me :)

https://lgtm.com/rules/2154840805/

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.

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array (if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string.

http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

This is true, and many people don't realize it. I used to call a wrapper function that would always set the last byte to 0.

I never could really understand the point of strncpy()... we always end up wrapping to deal with writing an unterminated string.

Was it intended for fixed length records?

In the interest of satisfying pedantry I think we can agree that strncpy() is intended to be a safer strcpy() for a subset of uses.

As you say, it does in fact obviate some errors. A value judgement as to which behaviors are more or less safe may be subjective, but the intent is not.

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.

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.

In a compiled language, when you remove a function it fails to compile. So removing them from the standard library forces code changes - they're not usually drop in replacements because the semantics were wrong in the first place.

Removing strcpy would make the Python transition look easy.

The expectation of a C89 programmer is that a valid C89 program can be compiled for any machine that has a C89 compiler, and likewise for C95, C99, C11, and C17. Furthermore, it's expected that any C89 program can be compiled unchanged on any future version of C, and the standard library is part of the definition of the language, and therefore functions cannot be removed.

The C Standard Committee doesn’t actually ship a compiler the way the people behind Java, Python, Lua, C#, Go, Rust, etc. do. The best they can do is deprecate particular functions and hope compiler writers and standard library writers follow along. But the compiler writers have vocal customers who insist the depreciations are overly-cautious.

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.

It's not great if you're working on a new release and you realize you also need to change something unrelated because the language changed under you, especially if it's just a bugfix but a high-priority one, or consider the head-aches caused by source-only distributions suddenly breaking for all your new users (or existing users switching to a new computer or spinning up a fresh VM).

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"

strlcpy() isn't standard. You have to provide your own implementation if you want your code to be portable.

This is something git does. That's why they prefer it - it's available to git everywhere.

These still lead to lots of bugs via off by one errors on lengths or other buffer misuse.

What’s scary is programmers assuming any function as being safe. C programmers don’t trust anything, and they’re better programmers for it.

This statement is not even wrong. Good programmers of any language are aware of the footguns in their language and the things their compilers assume. Bad programmers don't.

C has unsafe basic functions because the programs written then were much simpler, and this sufficed. There's decades of PL research resulting in new languages that give better guarantees than C, allowing you to worry less about wrestling with the language and more on your business logic.

> C programmers don’t trust anything, and they’re better programmers for it.

By that dime, frontend JS programmers trust things even less than C programmers, and they're even better programmers for it. \s (in reality, FE JS devs mainly wish that browser environments were more consistent and predictable, and would disagree that they are better developers because of it).

That's an unfortunate result of backward compatibility. If it were Python, it would just become v2 and tell people to suck it up.

Notice that it's a giant PITA to work with any variable-length data. Because language lacks adequate means to abstract away safe fast memory access with generic types, RAII and borrow checkers. Comparing to C, both C++ and Rust (very different beasts) feel like pals of JavaScript: basic operations with dynamic strings and arrays just work™.

Well that's input validation for ya. It's not enough to say "give me a string", or even "give me a file path", and then only check that it has ASCII characters. You have to validate that this input could conceivably be a file on this system that someone would use.

"../../../../../../../../../../../../../../../../../../../../etc/shadow" is not a file someone would ever reasonably want to access. But is there an easy way to look for nonsense paths without potentially limiting functionality, or writing more code than you wanted to? Nope.

The same footgun exists in all languages; C's design just has a hair trigger.

That example is typical "confused deputy" security vuln irrespective of the language, not a "validate input" one. Meaning, the typical unix interface to the filesystem is such that it's hard/impossible to express "i'm only having access to this folder and interested in paths within that folder". `chroot` is too dramatic sandboxing that cannot be used for all use cases.

BTW, in macOS there are "secure bookmarks" (see NSURL docs) that are effectively capability tokens: when user drags a file, or selects it in an Open File dialog (which runs isolated from the app), the kernel creates an app-specific token that grants access to that file to the app, so it can access it beyond its sandbox.

I remember an entire lecture about the use and abuse of sprintf and related functions as a means of exploit. Yeah, when you delve into the internals of C you find things that are terrifying if you are concerned about reliability, security, or performance. The same is true though for many languages. The problem is, as is often the case, the Iron Triangle: good, fast, cheap - pick two. Different sections of the language are written by developers under different constraints and pressures, which leads to different choices. In my experience every language implementation has at least one area that was done quickly for expediency or done poorly because no one else was able to (or wanted to) work on it.

I was hoping that someone would have already pointed out that this is not quite correct phraseology, as the qualifier "old ways to" has to be inserted: e.g. "old ways to get time in GMT". The "new" ways have been around for nigh on 30 years in some cases, and aren't really "new" now. I've been using localtime_r() for almost that long, for example. Coming from another language, don't be fooled into thinking that what you are looking at in these lists is the current state of the art for the language.

C is a well-stocked kitchen of a language.

Unfortunately, it is riddled with sharp knives that can cut you, open flames that can burn you, gas that can smother you, water than can drown you and food that can make you sick if you prepare it incorrectly.

Some react to this potential safety threat by banning the use of knives, stoves, sinks, and food from a kitchen.

Fortunately most attempts at safety just require having a microwave to prepare the frozen pizza or Uber Eats delivery.

Strings are half the reason I never recommend someone learns C as their first language. Python is much easier, and then you can pick up C afterwards when you've got a better baseline knowledge

I've seen the same question posted way too often by beginners to C. "I've created a char*. Why am I getting <random fault> when I try to write to it?"

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.

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.

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.

For what it's worth, while what @Camillo says is both true and important, people usually do not mention the trade offs involved or why that decision was attractive at the time.

These days (ptr,size) is probably 16 bytes -- longer than almost all words in the English language (the scrabble SOWPODS maxes out at 15). A pointer alone is 8B. Back at the dawn of C in 1970, memory was 7..8 orders of magnitude more expensive than today..(about 1 cent per bit in 1970 USD). (Today, cache memory can be almost as precious, but I agree that the benefits of bounded buffers probably outweigh their costs.)

8B pointers today are considered memory-costly enough "in the large" that even with dozens of GiB machines common, Intel introduced an x32 mode to go back to 32-bit addressing aka 4B pointers. [1] There are obviously more pointers than just char* in most programs, but even so.

Anyway, trade offs are just something people should bear in mind when opining on the "how it should be"s and "What kind of wacky drugs were the designers of language XYZ on?!!?".

[1] https://stackoverflow.com/questions/9233306/32-bit-pointers-...

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.

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

Sure, but parent wasn't saying "it was not possible", they said "It was too expensive".

And sure enough, the market drifted to the cheaper solution: you could run slightly more applications if your OS and applications were all written in C than if they were written in Pascal, Modula, etc.

If they would have used a "fat strings" for the standard lib there would have been at least four different types by now with 8 to 64 bit lengths. Maybe even with signed char as length field on some systems, unsigned char on other. Or signed and unsigned for all int:s for a total of 8 types.

I think the sentinel character was the best choice in hindsight and at the time in that regard.

But I wish the xxx_s versions and strdup would have made it into the standard like 30 years ago.

There are no C standard functions, aside from malloc(), calloc() and realloc(), that have to allocate memory to work. I think that's intentional on the part of the C standard library.

What you call "format a string" is actually "begin a perilous expedition into uncharted memory".

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 the rules were:

* 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,

* any constructs that would prevent statically calculating stack usage were banned (for example any form of recursion except when exact recursion depth is ensured statically),

* any locks were banned,

* absolutely every data structure must have size ensured, in a simple way, beyond any reasonable doubt,

etc.

It is interesting to read the rules you came up with to limit memory usage, and then to think of the criticisms one gets in Java for limiting memory usage. In Java we try to limit new as much as possible to prevent the GC from pausing too much, or inconveniently, or for too long. And basically all the rules you say are what we also use in Java.

Except when you have these rules in Java, the ironic counter-point is "if you are doing this much memory control yourself, you should just use C or C++ or something".

I'll keep your comment in mind next time I see that rebuttal. Thank you.

Having almost 20 years of experience with Java... but are not following recent garbage collector developments.

There is a bunch of misconceptions about Java. Java is actually very performant and memory allocation is generally cheaper than in C (except for inability to have good use of stack in Java). What's slow about Java is all the shit that has been implemented on top of it, but that's another story for another time.

For example, allocation in Java is basically incrementing the pointer. And deallocation for most objects is basically forgetting the object exists.

No, you don't want to "limit the use of new", that's wrong approach.

What you want is to have objects that are either permanent or last very short amount of time.

The worst types of objects are ones that have kind of intermediate lifetime ie if they are allowed to mature from eden. These cost a lot to collect.

The objects that have very short lifetime are extremely cheap to collect.

So if your function takes arguments, creates couple of intermediate objects and then never returns them (for example they were just necessary for inner working of the function) and your function does not call a lot of other heavy stuff, then it is very likely the cost of those temporary objects will be very low. Also, they tend to be allocated very close to each other and so pretty well cached.

This was very insightful. Thank you.

Well that seems to align pretty well with Entities/Aggregates and ValueObjects in DDD.

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 static one, with values precalculated and copy/pasted to current project source. This was a fun one to do maintenance work years later.

- magic numbers inside code was forbidden. All numbers had to be defined in a specific header, with explanation why is that number said value.

- no variable parameters. All functions to have fixed parameters

- use of macros as minimum as possible. Code review was wasted sometime on 50% time over use of macros that were not already "classic" from the project point of view

- operator overload strictly forbidden. Also overloading functions was forbidden too.

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?

Maintenance reasons. Future juniors to not have problems diving into projects directly. Chaining several ternary operators in same line is great to showoff your C prowess but a PITA to decipher what was doing, hence the rules.

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

MISRA: "Motor Industry Software Reliability Association"

https://en.m.wikipedia.org/wiki/MISRA_C

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 to fix performance issues fast enough due to allocations firing off left and right in the middle of a request.

I never realized that my view of C programming is heavily influenced by MISRA until your comment.

I know game engine programming follows a similar, perhaps unspoken, convention.

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.

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!

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program?

Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

In my experience dynamic allocation is banned in either (a) small embedded environments or (b) high scrutiny environments (soft realtime, safety critical, etc).

In both cases the project size is small enough, or the scrutiny is high enough that the ad-hoc allocator doesn't develop. The environment is also simple enough that the memory cheats you're thinking of don't exist (or you can squash them by touching all allocated memory up front).

Why would you want to implement your own allocator?

The goal of these rules is to improve reliability and timeliness of your application. If you intend on working around those rules to do what the rules explicitly forbid then either you or the rules are wrong.

Suppose your problem intrinsically has variable numbers of variable size records coming and going at runtime. Sure you can allocate a big array upfront. But it seems to me that the code which directs records to slots in this array is an allocator.

> How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program?

You could maybe call filescope buffers with an size counter a dynamic memory allocation. I.e. for storing RS232 or CAN messages. Since they shrink and grow.

The important thing is that you want to know that flooding one buffer wont flood another, which malloc could result in if it was used for unrelated buffers.

> Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

That depends on the OS. Linux lies (overcommits), Windows doesn't. In embedded it's more typical to have a special OS like VxWorks or FreeRTOS that don't lie to you, or to have no OS at all (like basically every arduino project)

Linux doesn't lie, it is just probably not doing what your simplified view of memory allocation is.

On Linux memory allocation is basically assigning range of address that may or may not be backed by pages in physical memory.

This allows doing a lot of interesting and useful stuff.

If you really want the memory for some reason (for example you need to guarantee your operation finishes without running out of memory), you need to touch the pages or force them in some other way (for example using mlock()).

It is just that developers are mostly oblivious how memory management works on Linux and then are surprised that it doesn't exactly do what they want.

Most people I work with can't tell how much memory is available on a Linux box if their life depended on it.

It's an embedded system, it's very likely there's no OS in the first place.

Actually it is irrelevant whether you use an operating system or not.

One project I worked with these rules was on Verix OS.

The rules are more intended on reducing application complexity and unpredictability which is typically helping reliability regardless of the setting.

The stack thing was always the big worry for me. Without a comprehensive static code analysis tool that's hard to do. And runtime stack checking adds quite a bit of overhead, especially if you also have to worry about running on the interrupt stack and possibly switching.

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

One way I can think of is to include the banned.h after you have performed all init processes

(It would have to be in the .c files, not the headers, might not be so clean)

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?

From the commit messages

> The ctime_r() and asctime_r() functions are reentrant, but have no check that the buffer we pass in is long enough (the manpage says it "should have room for at least 26 bytes"). Since this is such an easy-to-get-wrong interface, and since we have the much safer strftime() as well as its more convenient strbuf_addftime() wrapper, let's ban both of those.

(https://github.com/git/git/commit/91aef030152d121f6b4bc3b933...)

> The traditional gmtime(), localtime(), ctime(), and asctime() functions return pointers to shared storage. This means they're not thread-safe, and they also run the risk of somebody holding onto the result across multiple calls (where each call invalidates the previous result). All callers should be using their reentrant counterparts.

(https://github.com/git/git/commit/1fbfdf556f2abc708183caca53...)

Yes, but every hapless user shouldn't have to go searching through a bunch of commit messages to find the suggested replacement. Bad UX.

It seems pretty safe to assume a developer contributing C code to git itself would know how to use git blame (or the GitHub interface for it).

I think you are confused this is not for any hapless user. Developers search through and read commit messages all the time.

The UX of using this list is not by manually searching through the list and seeing the reason behind them. You include the file together with the rest of your sources and now you get compilation errors if you try to use them. Can't think of a better UX for banned functions.

Discovering why the thing is banned you only have to do once, if you care. If you're just modifying something quickly and minor in Git, you might not even care why.

Strangely there is no mention of strtok which has a similar issue.

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.

But why put that info in commit message instead of a comment in the file itself?

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!

Or even in the compile error message itself.

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

Commit messages like that are common in the Linux kernel project, which is where git came from (though this particular commit message is a bit on the longer side).

It makes more sense if you think of it as an email message justifying why the project maintainer should accept that change, because that's what they were before git even existed. Still today, unless you're one of the Linux kernel subsystem maintainers, you have to convert your changes to emails with git-format-patch/git-send-email and send them to the right mailing list. Even the Linux kernel subsystem maintainers keep writing commits in that style out of habit (and because Linus will rant at them if they don't).

Also, why the functions are banned.

It would be even nicer if it redefined the call to a safe version and then generated a warning message informing the programmer of the substitution.

You can't do that because the semantics are different in most cases.

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 can isolate that part of the code that has the strncpy/etc. and run gcc on it. Gcc-- for certain cases (string literals, I think)-- can report a warning if "n" has been set to a value that could cause an overflow.

I'm going to speculate that there was a period where C programmers were furiously committing a large number of errors to their codebases because the "n" stands for "safety."

Meh, most of us understood the sharp edges of strings pretty well. Before, we'd check the len of strings before strcpy, strncpy let us do it without doing that, and just slap a 0 in if needed. Safe? No. Better? A bit. Do I ever want to do string manipulation again with C? Nope.

Understanding the sharp edges is one thing. Being able to avoid them in practice is another. The history of memory safety problems in C string handling, especially involving strcpy/strncpy, strongly suggests to me that they're unavoidable even for C programmers who are skilled, knowledgeable, and experienced.

As an embedded programmer mostly working with C who considers themselves skilled, knowledgeable, and experienced...

I agree.

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.

Should have let me use strncpy then, shouldn't you? ; P

It would be interesting to see the rationale behind these bans, and what the suggested alternatives are. Some are obvious, like `strcpy`, but I can't remember what the problem with `sprintf` or the time functions are.

If you are doing something like `sprintf(buffer, "%f, %f", a, b)`, yes it is tricky to choose the size of buffer frugally, but if you replace that by `ftoa` and constructing the string by hand, you are likely to introduce more bugs.

Edit: as pointed out in another post, you can do git blame to see the rationale for each ban, quite interesing.

The trouble with printf-family functions is their variadic nature. If the arguments don't match the format string, you can wreak all sorts of havoc.

A fun exercise you can do is put a "%s" in the format string, omit the string argument and see what happens to the stack.

That's however relatively easy to verify programmatically, and indeed any recent compiler will complain about that.

I'd say the usual trap is rather the size of the target buffer, because that requires bigger static analysis guns. (I'm ignoring things like "%n", because then you're playing with fire already.)

I think the big three C compilers have pragma's that you can tag printf/scanf with that will cause the compiler to verify the argument list.

There's that, but with sprintf/vsprintf specifically, there's no way to keep it from storing characters past the end of your buffer. For example:

    char buf[2];
    sprintf(buf, "%d", n);

This will happily write to buf[2] and beyond if n is negative or greater than 9.

This was my reaction as well. Banning strncpy just encourages haphazard manual copying.

From the commit message:

If you're thinking about using it, consider instead:

  - strlcpy() if you really just need a truncated but
    NUL-terminated string (we provide a compat version, so
    it's always available)

  - xsnprintf() if you're sure that what you're copying
    should fit

  - strbuf or xstrfmt() if you need to handle
    arbitrary-length heap-allocated strings

I think you're meant to use snprintf instead. It would be great to see documentation on the alternatives!

maybe this https://github.com/git/git/blob/master/strbuf.h ?

strlcpy is the safe way, that is used by git.

strncpy doesn't do what you think it does (it is not analogous to strncat). strncpy does not terminate strings on overflow. In C terms, it is not actually a string function and shouldn't be named with `str`.

snprintf or nul-plus-strncat do what you want, but snprintf has portability problems on overflow. Most projects I've been on rely on strlcpy (with a polyfill implementation where not available).

snprintf will always terminate the string, and won't overflow the buffer.

sprintf() warnings have gotten pretty sophisticated these days. I discovered GCC's -Wformat-overflow the other day. It complained that the buffer for a date string wasn't big enough; e.g., sprintf(buf, "%04d-%02u-%02u", year, month, day), where year, month, and day are 16-bit shorts, and buf was probably eleven or twelve bytes.

It may actually be a bug that I got the warning, because the range of each input was checked, and I think the compiler is supposed to be smart enough to remember that.

These functions are one of the many reasons why I tend to have a C with some C++ classes dialect I use in my own projects.

std::string needs some tweaks, but it can mostly be treated as a built in and it wipes out a huge set of C string issues.

I have only ever dabbled in C, just to look at other people's code and occasionally when I really needed speed, so I am at what I would call a "Pretty Pathetic" level, able to recognize that I am looking at C.

However, I look at old books on C, and then I look at this list, and I wonder if it would not have been helpful to, after mentioning that a function was banned, suggest what the replacement is, even as a comment.

You're not wrong. But a seasoned C developer looks at this list and nods along. (I'm a little out of practice, but I have war stories for most of these).

It's likely that the authors of this list didn't think the comments would be worthwhile for the audience (git developers).

I wonder how they copy strings with strcpy and strncpy both banned. strlcpy? But it is not conforming to major standards. Or just memcpy with extra code?

Edited: Looks like they have safe alternatives: "

  - strlcpy() if you really just need a truncated but
    NUL-terminated string (we provide a compat version, so
    it's always available)

  - xsnprintf() if you're sure that what you're copying
    should fit

  - strbuf or xstrfmt() if you need to handle
    arbitrary-length heap-allocated strings
"

https://github.com/git/git/commit/e488b7aba743d23b830d239dcc... Yes:

> we provide a compat version, so it's always available

This gets me interested. Link [1] below shows their implementation of strlcpy(). This is a questionable implementation. With strncpy, the source string "src" may not be NULL terminated IIRC. The git implementation requires "src" to be NULL terminated. If not, an invalid read. EDIT: according to the strlcpy manpage [2], "src" is required to be NULL terminated, so strlcpy imposes more restrictions and is not a proper replacement of strncpy.

Furthermore, imagine "src" has 1Mb characters but we only want to copy the first 3 chars. The git implementation would traverse the entire 1Mb to find the length first, but a proper implementation only needs to look at the first 3 chars. So, they banned strncpy and provided a worse solution to that.

[1]: https://github.com/git/git/blob/master/compat/strlcpy.c

[2]: https://linux.die.net/man/3/strlcpy

You have found the answer - strlcpy is not a replacement for strncpy at all (it's arguably a safer version of strcpy), and git people didn't invent this, it's the existing BSD strlcpy interface.

Agreed. It's O(n) inefficient. I guess looping though chars up to `size` would perform better on average.

I see this `strlcpy` recommanded everywhere.

Take a step back and consider strlcpy isn't supposed to be a drop in replacement for strncpy (a function which already exists).

strncpy is a dangerous function because it doesn't nul terminate on overflow. The danger is that it's named misleadingly (str* functions otherwise always work in nul-terminated strings).

(strcpy is just banned because there's no bounds check, and they want to force use of strlcpy instead).

strncpy also has the dubious behavior of zero-filling out to N even if strlen(src) is much shorter than N.

memccpy? Most platforms have it, and it's being added to C2X.

See https://developers.redhat.com/blog/2019/08/12/efficient-stri...

To its credit, it's convenient that the C pre-processor is so powerful that it facilitates baking a "C the good parts" concept directly into the compilation process.

In compilers that implement GCC extensions (such as Clang), you can use the "poison" directive to achieve the same effect (but with a better error message):

#pragma GCC poison printf sprintf fprintf

[0] https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Pragmas.html

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

Should be easy to implement, will have a pull request ready tomorrow.

Edit: wait, I can't use strcpy?! Screw that, then I'm not open sourcing my AGI!

Funnily enough, strtok() is not listed :)

This one has my vote for the weirdest library function ever.

The storing of state between calls is beautiful in all its wickedness.

They should probably add sscanf.

First thing I looked for. It looks like it was used here:

https://github.com/git/git/blob/master/object-file.c#L1293

And currently used here (at least):

https://github.com/git/git/blob/master/refs.c#L1235

Some functions are missing which would normally cause a warning with most linters and static security analysis tools (e.g. the atoX family, mktemp, etc ...). Problem is most people I know don't run external linters (maintaining good linting rules is hard to scale in larger projects and in my >3 decades of writing C only few companies[0] I've seen managed the linting rules as part as their "definition of done").

While I think such rules are a good idea it only makes sense if it is done consistently and depends on how religiously the tooling (duct-tape and "process") enforces them (even so, you're still only one `#ifdef` away from undoing that "safety"). Having GCC[1] now support static analysis is a killer feature for this type of problem.

On the other end of the spectrum we have Huawei which instead of linting their code is finding creative ways to trick auditing tools and hide such warnings from auditors:

[0] https://news.ycombinator.com/item?id=22712338

[1] https://developers.redhat.com/blog/2021/01/28/static-analysi...

[2] https://grsecurity.net/huawei_and_security_analysis

The Git Mailing List Archive on lore.kernel.org (found in the README from the git mirror on GitHub) has more context [0] [1] [2]. From Jeff King on 2018-07-24:

  The strncpy() function is less horrible than strcpy(), but
  is still pretty easy to misuse because of its funny
  termination semantics. Namely, that if it truncates it omits
  the NUL terminator, and you must remember to add it
  yourself. Even if you use it correctly, it's sometimes hard
  for a reader to verify this without hunting through the
  code. If you're thinking about using it, consider instead:

    - strlcpy() if you really just need a truncated but
      NUL-terminated string (we provide a compat version, so
      it's always available)

    - xsnprintf() if you're sure that what you're copying
      should fit

    - strbuf or xstrfmt() if you need to handle
      arbitrary-length heap-allocated strings

I just did a search on the keywords 'banned' and 'strncpy' [2]

[0] https://lore.kernel.org/git/20180724092828.GD3288@sigill.int...

[1] https://lore.kernel.org/git/20190103044941.GA20047@sigill.in...

[2] https://lore.kernel.org/git/20190102093846.6664-1-e@80x24.or...

[3] https://lore.kernel.org/git/?q=banned+strncpy

Psst:

https://github.com/git/git/commits/master/banned.h

(Git development is done by emailing patches. Those patches include the git commit message, which we can see just by looking at the history of the file. Sometimes there's additional discussion on the ML, but the most important details are in the commit message because the git development team is very disciplined about that.)

Ha, yep, whoops

It would be great if the BANNED() macro could suggest the correct function to use.

The right function may change based on the use case, that's why they may not have wanted to suggest an alternative outright.

You could send a pull request, it doesn’t seem too complicated to implement

The similar list from ClickHouse repository: https://github.com/ClickHouse/ClickHouse/blob/master/base/ha...

Are there some details on whats wrong with these?

The commit messages that added them explain the reasoning

I wish they would have put that on comments instead of on the commit messages. It's not the first time that I've seen this particular list of banned functions being shared online and every time it happens someone has to explain that the most interesting info is hidden in the commit messages.

All the string functions have buffer overrun vulnerabilities if not used carefully. I'm not sure about the time functions though.

The time functions are either non-reentrant, or, for the _r versions, have the same problem with buffer overruns.

https://github.com/git/git/commit/1fbfdf556f2abc708183caca53...

https://github.com/git/git/commit/91aef030152d121f6b4bc3b933...

Very much this. I frequently write small games in C, and the number of times I have been bitten by baffling behaviour because a string somewhere was copied into an array that was too short, are many! Apart from that, I love the simplicity of the language and the stdlib, and it's definitely my preferred hobby programming environment.

It would be good to know what the commonly-accepted alternatives are.

I'm pretty sure you could google each of these with the word 'dangerous'

For example: https://lgtm.com/rules/2154840805/

At least they didn't ban memcpy()...

Much like with all other forms of effective censorship, I see this as a quick short-term "fix" with hidden long-term costs[1]. IMHO this sort of anti-thinking just leads to even worse, more dogmatic and cargo-cult, programmers who know less and less about the basics and then go on to make even more subtle errors.

Somehow the collective software industry has managed to propagate the notion that people are incapable of doing even basic arithmetic. Yet they think people are capable of creating complex systems with even more subtle behaviour? The justification would normally be because it's not directly affecting security. WTF. It's beyond stupid.

The only C function I think should be truly banned is gets(), because it is actually impossible to calculate what size of buffer it needs. That is not true of any of the others on this list.

[1] By short and long, I mean decades vs centuries.

OK, so no strncpy, strncat etc, what are the alternatives used in git then? I'm a long-time C coder but I do not know what will be used to replace strncpy/strncat and all those gmtime/localtime/ctime/asctime.

Ah this is a very good idea. I guess you still have to make sure that all your translation units include this header, which isn't completely foolproof.

Static analysis would probably be more robust, but way more involved.

Best of both worlds: use static analysis to ensure the header is included?

gcc has a -include option, so this can be done once in the Makefile and get the benefit everywhere (unless you’re being clever).

I remember visual studio having an option to force include a file, surely something like that would exist for other toolchains

You don't need fancy static analysis. You can find out whether the banned functions are called just by inspecting the compiled object file. Add it to the build step and done.

Previous discussion: https://news.ycombinator.com/item?id=20792938

Our forbidden functions header is similar; it's got about 30 functions including most of the str* family to enforce the use of our safer versions.

Is there no linting software that can catch these kinds of issues? Like using strlen with sscanf like I've been hearing about lately?

I am so thankful git isn't forcefully including this header in every C language project and that we have a choice when using git! :-)

I used C many years ago so I’m quite out of it. What are the replacements for these? I would have thought these were all necessary.

Let's use a loophole ;) - (strcpy)(a,b)

Now I am getting really curious whether other companies with supposedly strong engineering knew about sscanf issues.

Just replace strcpy(a,b) with strcpyn(a,b,INT_MAX)

/joke

I'm pretty sure I've seen similar logic in my life.

Been a while, eh?

It should be strncpy(a,b,(size_t)-1)!

SIZE_MAX does exist.

What would be helpful is an explanation of how each function ends up being misused so people can learn from this.

Git blame is helpful here. See e.g.https://github.com/git/git/commit/1b11b64b815db62f93a04242e4...

View the git history for the file. Each commit that adds functions has a detailed explanation of what is wrong with the functions.

About 20 years too late. Those should have been moved to a "deprecated" header file decades ago.

Maybe instead of just writing a banned message, it should be the name of alternative function to use.

Yes, this is right. Any C decent programmer knows that functions are cursed.

I hope, one day to see it's rewritten in a safer language.

There's a nice Go implementation of git: https://github.com/go-git/go-git

gets() and scanf() should be on that list due to potential buffer overflow.

why is strncpy banned? what's wrong about it?

Can a C guru provide a TL;DR of why these are bad?

    - strcpy: no bounds check
    - strcat: no bounds check
    - strncpy: does not nul-terminate on overflow
    - strncat: no major issues, probably to force usage of strlcat
    - sprintf: no bounds check
    - vsprintf: no bounds check
    - gmtime: returns static memory
    - localtime: returns static memory
    - ctime: no bounds check
    - ctime_r: no bounds check
    - asctime: returns static memory
    - asctime_r: no bounds check

The str functions all have safer alternatives. The time functions have reentrant alternatives, and/or alternatives that provide a bounds check.

getc?

`gets` would be the ultimate banned C function, I suspect nobody thought it was worth spelling out though.

scanf?

Just banning is not fair; Include the alternatives;

Reply on news.ycombinator.com