It's a classic case of moving the complexity from one part of the system to another. "Strings are just character arrays" seems simple and elegant, but in reality is a giant mess, because strings are not just character arrays, any more than dates are just an offset from an epoch.
Human concepts are inherently messy. "Elegant" solutions just shove the mess down the road.
Re:Git's list of banned C functions
by lultimouomo on Thursday March 04, 2021 @06:05PM
(#26349773)
On the contrary, I think "Strings are just character arrays are just pointers" is the solution, not the problem. As with non-character arrays, you must always pair the pointer with a length. (I don't like the idea of prefixing the length because it prevents su stringing).
The problem is the null termination, which is not general to arrays (though it is sometimes used with arrays of pointers).
Re:Git's list of banned C functions
by ByteJockey on Thursday March 04, 2021 @09:18PM
(#26351674)
You sometimes see sentinel values used with varargs (only if they're all the same type), which is basically just an array with more boilerplate.
That being said. Length as a first parameter and the rest of the arguments being the variadic bit is also quite normal.
You're just moving the complexity from strings into unsigned integers. Your strings are limited by the size of whatever you put in the head of the string.
Sure 16 exabytes sounds like a lot today, but so did 4 billion ip addresses. Differently bad is not better.
I didn’t say anything about unsigned integers, or any specific approach to encoding strings at all, so I’m not sure what you’re trying to say here.
Re:Git's list of banned C functions
by bobbyi_settv on Thursday March 04, 2021 @06:11PM
(#26349831)
It doesn't just buy safety. It also makes it possible to include null bytes inside of strings.
This is the part that boggles my mind. It's not like fat pointers just didn't exist at the time. You need fat pointers any time you do anything with dynamic non-string binary data.
Null is always 1 byte minimum so at best you save size_t-1 bytes per string. Ignoring clever structures like LEB128 varint length.
This is a classic case of "simple is actually complex". How many billions of dollars has null terminal strings cost? Hope that 3 bytes of overhead per string saved is worth it.
In hindsight, I think the complexity is worth the safety, but I could see why it felt more elegant to use null-terminated strings at the time.