2 ms·

> so you have to decide what to do about that No, you need to do what needs to be done according to the on-disk format. The disk doesn't care what you think is

> so you have to decide what to do about that No, you need to do what needs to be done according to the on-disk format. The disk doesn't care what you think is the ideal string representation. If the available space is used up, it is used up. That's just the semantics that come with the physical reality of existing systems where you can't just malloc an extra space on the heap. Having an internal representation that matches what's on the disk is the right call, everything else is only layering complexity. Also, you're making it look like it was hard to use, but those semantics are very easy to program against, using something like snprintf(buffer, sizeof buffer, "%s", ...), or just do it manually.

tialaramex 4y ago
Maybe the problem you've got is that you actually haven't understood what the alternative you don't like even is in practice ? // Assuming buffer is a mut [u8] and text is the text value we'd like to write into it // if we've got some string, just let text = string.as_bytes(); if text.len() > buffer.len() { // As with snprintf we need to decide what to do if it won't all fit // ... for example let's just truncate it let truncated = &text[..buffer.len()]; buffer.copy_from_slice(truncated); } else { let (left, _) = buffer.split_at_mut(text.len()); left.copy_from_slice(&text); } As I thought I'd explained, the yak shaving problems for your C-style strings are on the other side, reading this structure. With pointer + length strings this is no trouble but with a 0-terminated string you have to conjure that sentinel from somewhere, maybe allocating in the process. Slower and uglier.