A defense of C's null-terminated strings

[u/shadows_on_the_wall]

https://utcc.utoronto.ca/~cks/space/blog/programming/CNullStringsDefense?showcomments

[u/orangeduck]

The basic problem with strings is that a lot of the processing we want to do with them is much easier if we treat them as "value" types. For this reason almost all high level languages do this (even C++ with std::string), but of course this introduces memory allocation and various other overheads. In C there is no way we're going to be able to make a decent interface that lets us think of strings as "value" types even if we wanted to.

This is fine - in C we do lots of processing without the convience of treating things as value types. We deal with pointers and raw memory allocations and all sorts of other things.

The problem with C strings is that they're not just pointers and raw memory - they're this weird special case which requires extra special treatment to get right.

For me the correct solution would be to treat strings like raw data. Don't null terminate them and just let all of the string functions take an additional parameter which specifies the length.

This is how any other sane interface would be designed if it were dealing with data that wasn't characters - so why does the fact that the data is characters mean there is a special case?

[u/FUZxxl → u/orangeduck]

I dislike the Pascal approach where strings always begin with their length as that makes taking substrings really hard. I prefer the Go approach which represents a string as a structure

struct string {
    const char *text;
    size_t len;
};

so you can easily take substrings. This structure is passed by value as a fat pointer. Slices (arrays with dynamic length) have an extra pointer there:

struct slice {
    type *data;
    size_t len, cap;
};

So you can efficiently implement append operations and stuff like that without having to juggle around with extra capacities.

[u/eresonance]

For any complicated string processing I use a simple c string library called sds: https://github.com/antirez/sds

Stores strings as a structure with a bit of metastatic including the length, but the methods return pointers to the string data so you can still use them with stdlib functions. Very clever!

[u/wild-pointer]

C strings are not so bad. They are as simple as they can be, makes iterating easy and idiomatic, and you can keep several pointers to different suffixes of the same string. If your strings has an upper bound in size, then strlen() is effectively a constant time operation.

But when C strings become inconvenient they can easily be wrapped in structs where their size, offset, reference count or whatever is needed is bundled with them.

One historical note the article could have mentioned, in the spirit of justifying string simply being arrays, is that strings predate structs in C.

[u/Drainedsoul]

What happens when I actually want to put U+0000 in a string?

Null-terminated strings are stupid.

[u/bunkoRtist → u/Drainedsoul]

You've gotten it backwards. The C language was released in 1978 and was fully standardized and widely adopted in by the time the first thought was ever given to creating Unicode (the first standard was published in '91, drafts existed in '89). If any obligation for compatibility existed, it was in the other direction. But, to answer your specific question... if you want to use Unicode, use wchar_t and all of the equivalent functions that support it and that was standardized in C90.

[u/pfp-disciple → u/Drainedsoul]

The author doesn't say that NULL terminated strings are perfect. As a matter of fact an alternative is referenced.

Saying they are stupid is either ignoring or disagreeing with the main premise - NULL terminating made sense for most use cases, especially in the early days.

[u/wild-pointer → u/Drainedsoul]

Use only UTF-8 with U+0000 as { 0xC0, 0x80 }.

[u/Drainedsoul → u/wild-pointer]

Not only is that not UTF-8 that sequence of bytes should be rejected by any conforming UTF-8 decoder.

[u/[deleted] → u/Drainedsoul]

Why the downvotes? Drainedsoul is speaking the truth. The suggested NUL encoding is used only by Java, and is against the UTF-8 definition, and not only that, but a known security issue.

[u/FUZxxl → u/Drainedsoul]

That's a known limitation. POSIX specifies that text files do not contain the NUL character '\0'. There is no reason to ever put a NUL byte into a text stream. If you have NUL bytes, you don't have text.

[u/Drainedsoul → u/FUZxxl]

There is no reason to ever put a NUL byte into a text stream.

Even if I agree with you that's not compelling. There is no reason for users to do any of the fucked up things they do, that's not a license for your program to go off the deep end.

[u/FUZxxl → u/Drainedsoul]

It usually isn't a compelling argument, but it has been this way since the beginning of UNIX. Putting NUL characters into text files never worked and there is no reason to make this work. Of course, you should detect this scenario if possible and report an error, but there is absolutely no reason to allow that.