Yeah, there might be a few cases were null terminated strings work okay but mostly they are just a recipe for buffer overflows. Seriously, how many years is this going to take to figure out?
Besides the fact that you have to walk the string just to find the length of it...
Null-terminated strings try to save space by encoding the string length by convention. This can fail due to off-by-one errors, mistakenly allocating a fixed buffer, strings that have an unexpected null in them, and more.
Those can lead to all kinds of nasty problems like buffer overflows, which allow someone who can craft an input to write arbitrary stuff into memory.
God only knows how many security vulnerabilities and performance problems could be traced back to null terminated strings.
I should have specified a little more, perhaps. Don't think of it as a null-terminated + length-prefixed string. It's effectively a purely length-prefixed string. There just happens to always be a null one byte after the end of the string.
The length prefix is the only thing you use, ordinarily. The only time the null comes into play is if you've already had a bug.
Yes but if we are being pedantic no. Of course the language does still greatly lean into the null terminated string concept.
You get a null terminated char array but the length is actually available since arrays (as long as they haven't decayed into pointers) can still share their length at compile time.
Actually, null-terminated strings made a lot of sense when the string is short. On my 8-bit days, I used both approaches (because, sometimes, strings have to contain a NUL in them)
> Correct string handling means that you always know how long your strings are
Well, I couldn't think of a stronger argument against NULL terminated strings than this. After all, NULL terminated strings make no guarantee about having a finite length. Nothing prevents you from building a memory mapped string that is being generated on demand that never ends.
I love screwing around with NULL terminated strings, but doing it correctly is a lot harder. NULL and the delimiter might not be the same length if the string is UTF-8 encoded for example.
IMO: if it’s not a hobby project just use a library for slicing and manipulating strings. Really you should think twice before doing it at all.
If the lengths are wrong. You said that the function shouldn't assume that strings are null-terminated correctly -- why should it assume that the lengths are correct?
This just makes me think that null-terminated strings are the bad gift that keeps on giving. If we were to design an OS, language, or standard library in 2021 (or even 1999) we probably wouldn't use them, but we're stuck with this relic of a former era.
> Null-terminated strings are useful for buffering values of unknown length (e.g. copying from a network stream).
That doesn't seem like a good example. The data arriving over the network arrives length-prefixed, because 0 is a legal byte value for arbitrary data. What do you then gain by throwing away your existing knowledge of the length?
reply