Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Note that "360 Patches" is 360 uses of strncpy that have been removed, not necessarily bugs.by D-Coder
- I would imagine 360 patches removed way more than 360 uses of strncpy. But yeah, it’s not a given that each of these patches addressed a bug. (Also not a given that there were only 360 bugs fixed.)by dpark
- I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.by senfiaj
- A lot of them are strings coming from or going to user space right? So wouldn’t you have to do constant conversions?by MBCook
- Pascal did/does this, but eventually someone wants a string longer than the size portion can handle. Or wants the number of characters not the number of bytes.by chiph
- It's definitely possible. And common, at least in some projects. The only real drawback is that sloppiness will lead to multiple slightly different nonstandard string types in the same project.by maxlybbert
- Yes I have seen it happen a few times with `strlen` being called in a loop silently causing O(N) to turn to O(N^2)by GalaxyNova
- The size overhead of that is 2*sizeof(int) while the overhead of null termination is sizeof(char). If I remember the standard right, the former is worse by at least sizeof(char), and usually more in practice. This used to matter, sometimes still does.
- That's called a fat pointer. Null terminated c strings is the majority of memory errors out there.by bnolsen
- Wonder no longer!
https://dlang.org/spec/arrays.html#dynamic-arrays
and
https://dlang.org/spec/arrays.html#strings
and for C:
by WalterBright - I worked on a Win32 app that used space-padded strings, i.e. the destination string was padded with spaces, but there was still a null on the last byte. You had to use special versions of the string functions for length, copy etc.
I’m not sure why this was - the source base was so old it might have had its origins in Pascal struct behaviour.
by PlunderBunny - Perhaps prevent realocation when string size changes? Or aligning cpu cache lines?by bebe83939
- I think this behavior has its roots in COBOL, not pascal.by egorfine
- It can perhaps be due to the string originating from a sql database ”char” field, I.e. not ”varchar”. Char fields in databases are space padded.by jkfkfkj
- The purpose of strncpy, which was originally part of the UNIX kernel code, was to copy file names to and from directory entries that consisted of a 2 byte inode number and a 14 byte zero-padded but not zero-terminated name field.
I started warning my colleagues against using it the moment I saw it for the first time about 50 years ago.
by jibal - strncpy appears somewhere around the Unix v7 time frame, however only as function in the standard C library. It is not used in the v7 kernel itself.by dare944
- A lot of pain and suffering to avoid having a string datatype.by cm2187
- What's a way they could get a strong data type here? Wouldn't that also require a large refactor of the code around strncpy to use the type and its functions?by edoceo
- > A lot of pain and suffering to avoid having a string datatype
No, a lot of pain and suffering to work around the lack of a string datatype in C.
by teo_zero - the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.by mrlonglong
- Almost as bad as newline-terminated lines. ;)by layer8
- Clang and GCC both let you use Pascal strings in C if you would like (with `\p`). But Pascal strings aren't that useful today because the maximum length is too short.by Conscat
- It was definitely an interesting way to allocate pointers. I did once have a very large project where devs didnt understand this and resolved hundreds or more off by one and memory overwrites in C due to this feature.
But at the same time, I think blaming the software was kind of a cop out. Devs were in a hurry and simply didnt respect the rules. Given todays software engineer at large. Nerfing programming languages so they cant destroy things might not be a bad idea. But AI will nerf everything.
by jackbucks - 255 characters ought to be enough for everybody, right?by dmazzoni
- Zero terminated strings were the basis for an awful lot of useful software. Calling them the biggest mistake in computing is a bit OTT.
I haven’t programmed anything Pascal related for 30+ years but I dimly remember thinking at the time that I wished the string system wasn’t so hard to use.
by smackeyacky - Partly agree but there would have been squabbling on the data type of the size, unless it was variable length. The latter would have had other issues too.
For a while, 16bit would probably have seemed too extravagant. Now 32bit would probably seem too small.
For a “strongly typed” language, C is pretty damn loose where would have mattered.
by BobbyTables2 - There is a middle ground that Visual Basic (and then COM) took, with the BSTR type: It’s still a pointer to a zero-terminated char array, but there is a length field immediately preceding the first pointed-to byte. This is still compatible with a C string (assuming no embedded null characters), but BSTR-typed functions can take advantage of the length value.by layer8
- Zero terminated string is a special case of sentinel value termination.
And sentinel value terminations make a lot of sense when you have punch cards and fixed length records that you need to carve into pieces.
Nobody expected any decisions they were making in the 1960s and 1970s to have any bearing on computing a half-century later. They all expected to have their mistakes long papered over by smarter people at some point.
But we ALL make the mistake of underestimating inertia.
by bsder - wow, very humbling. I'm actually amazed how many people contributed to this. It's easy to get attribution for "cool new features", but arguable removing bad features is even more important for something as fundamental as the kernel. Cudos!
I'm sure these are the sorts of things that will go down as folklore from the "founding ages", when everyone will have forgotten how to understand source code in 50 years and the Claude/Codex cruft just silently keeps piling on and burning the majority of our planets energy.
by twothreeone - I'm of the opinion AI slop code will become untenable way before that.by nuc1e0n