It doesn't because it would still need some other flag system to indicate if the string it is reading from a file is of the 1, 2, 3, or 4 bytes "header types" (and as a byte is the smallest single construct that can be written/read from a file...this seperate flag system would use it's own byte even if only a couple of bits within it are actualy used...)...and useing a special character to indicate the end of a string is kinda wasteful in that Blitz needs to allocate system memory to store such a string, which it will have to allocate a certan amount...read the string, and if the string is larger then this amount (Blitz hasn't reached that special character) it would have to re-allocate more memory to continue reading in the string...which can be a perfomance issue, but the real problem comes from that special character in that it completely limits what you can do with strings (imagine sending out a packet over the internet with the recieveing computer getting the special character before it gets the rest of the string...
Firstly, I've never mentioned wanting to use null-terminated strings. They aren't an issue at all. I merely mentioned in passing that null-terminated was the other way of storing strings, and NOT the one that I was interested in.
Nor do I have a problem sending my data over the network, in fact I use BlitzPlay which takes care of all that for me, even as far as compressing floats and ints into strings... so I don't have to worry about the exact format of messages.
My simple question is, why isn't my suggested string format used by Blitz (or other languages) for reading/writing to streams and files? There seems no logical reason why not, and in 99.9% of cases it is more efficient by 2 bytes per string.