ShortStrings.jl icon indicating copy to clipboard operation
ShortStrings.jl copied to clipboard

Null padded representation?

Open oxinabox opened this issue 5 years ago • 3 comments

cf #29 Rather than sorting the size at all we could store the string in null-padded form. This would let us use up to the full width of the backing primative for content.

Then to determine the ncodeunits we would count backwards from the end how meany consecutive bytes were not 0x00 and subtract that from the size of the backing primative

oxinabox avatar Nov 03 '20 13:11 oxinabox

I don't think that really works, because then you can't store strings with \0

ScottPJones avatar Nov 03 '20 14:11 ScottPJones

Yes, you can, so long as it isn't at the end. and if it is at the end, it is almost certainly a null-terminated string, and so you don't want to store it.

Its worth considering if handling strings that have nulls at the end but are not null terminated is worth giving up a whole byte.

oxinabox avatar Nov 03 '20 14:11 oxinabox

ShortStrings don't store a terminating null anyway. I've frequently needed strings that were just "\0", or had a '\0' at the end. Having to deal with a single byte "lost" is a lot better IMO than the quirky issues that would come up with allowing '\0' some places, but not others.

Once this is all working correctly (there are still the access violations, and any fallbacks that use String(val) should be rewritten, maybe you could make a ShortNTS package, that works that way.

ScottPJones avatar Nov 03 '20 14:11 ScottPJones