Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
1–10 of 58 posts
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#2>Using an address + length format would cost one more byte of overhead than an address + magic_marker format, and their PDP computer had limited core memory.
I find this interesting - why only one more byte of overhead? That would've limited string lengths to 256. So 2 bytes would seem the minimum, and even then, how do you go to 4 bytes once memory becomes cheap without breaking everything? Using NUL-termination, the upper bound for a string is effectively the amount of memory the OS is willing to give you, and code can keep working without modification for decades.
Am I missing something here?
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#3Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#4>Using an address + length format would cost one more byte of overhead than an address + magic_marker format, and their PDP computer had limited core memory. I find this interesting - why only one more byte of overhead? That would've limited string lengths to 256. So 2 bytes would seem the minimum, and even then, how do you go to 4 bytes once memory becomes cheap without breaking everything? Using NUL-termination, th…
Two bytes extra for the length, but one byte saved from the marker character.
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#5>Using an address + length format would cost one more byte of overhead than an address + magic_marker format, and their PDP computer had limited core memory. I find this interesting - why only one more byte of overhead? That would've limited string lengths to 256. So 2 bytes would seem the minimum, and even then, how do you go to 4 bytes once memory becomes cheap without breaking everything? Using NUL-termination, th…
1 additional byte of overhead would give you 2 bytes for the length, since you wouldn't have to have the NUL byte at the end of the string.
You could do some kind of variable int encoding scheme, where longer strings would require more bytes for length, with some overhead to indicate how many length bytes are required for each string.
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#6Did they choose "wrong"? No. Did they make a choice and move on? Yes.
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#7>Using an address + length format would cost one more byte of overhead than an address + magic_marker format, and their PDP computer had limited core memory. I find this interesting - why only one more byte of overhead? That would've limited string lengths to 256. So 2 bytes would seem the minimum, and even then, how do you go to 4 bytes once memory becomes cheap without breaking everything? Using NUL-termination, th…
[deleted]
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#8A null-terminated representation is as close to a fundamental datatype for a string as possible. It is same in spirit as other fundamental data types in C like array. People have built abstractions over these fundamental datatypes over the years.
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#9Worth keeping in mind that the security cost here is illusory: the track record of length-delimited data structures isn't much better than that of ASCIIZ, especially since integer handling in C is so treacherous.
Re: Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)
#10A null-terminated representation is as close to a fundamental datatype for a string as possible. It is same in spirit as other fundamental data types in C like array. People have built abstractions over these fundamental datatypes over the years.
It's not fundamental at all. You can't even represent null bytes in a null-terminated string.
A length prefix is pretty clearly superior.