News for hackers. Stuff that matters.
Re:Did Ken, Ritchie and Brian choose wrong with NUL-terminat... by IshKebab on Tuesday January 16, 2018 @01:44PM (#16160850)
I presume the machine at the time was 16-bit, and thus you could never have a string longer than 65536 bytes in memory.

On a modern machine you'd need at least 4 bytes. `std::string` uses `size_t` (64-bits on 64-bit machines).

Re:Did Ken, Ritchie and Brian choose wrong with NUL-terminat... by rzzzt on Tuesday January 16, 2018 @01:49PM (#16160914)
Length itself could also be stored with variable length encoding.
Re:Did Ken, Ritchie and Brian choose wrong with NUL-terminat... by PopsiclePete on Tuesday January 16, 2018 @02:11PM (#16161207)
That's what I mean though - if you standardize, as part of the language, that you can have 2 bytes for the string length because at the time no machine could handle anything larger, how do you move forward once 4 or 8 bytes is not a big deal without breaking everything?
Re:Did Ken, Ritchie and Brian choose wrong with NUL-terminat... by jandrese on Tuesday January 16, 2018 @02:26PM (#16161378)
Best solution would be something like SDNV. Short strings (up to 127 characters) have no length penalty and you can handle strings of any length.

I don't think these were invented back when K&R were designing C, but it feels like something any smart computer language designer could invent if the need arose.

Re:Did Ken, Ritchie and Brian choose wrong with NUL-terminat... by IshKebab on Thursday January 18, 2018 @09:10AM (#16177097)
N-bit machines can use N-bit lengths for strings in memory. If you're storing strings your storage format has to specify a way to decide the prefix length (or you can use some other system).

For example `std::string` uses `std::size_t` as a length which is 32-bit on 32-bit machines and 64-bit on 64-bit machines. When you serialise a string to protobuf (for example) it uses a variable-length prefix. Other formats could have fixed 4-byte prefixes or whatever they want (even null-terminated).