[rust-dev] strings, slices and nulls

Kevin Cantu me at kevincantu.org
Fri Apr 20 20:33:05 PDT 2012

The cost isn't an extra byte of storage.  The cost is that every slice
will have to be a copy+append.

Both D and Go have special slice types to store pointers and offsets
to the underlying arrays/strings, so slice operations can avoid that
hit, IIRC.

Kevin Cantu

On Fri, Apr 20, 2012 at 6:20 PM, David Piepgrass <qwertie256 at gmail.com> wrote:
>> My preference is to remove null termination:
>> * I'm guessing most strings aren't passed to C. (What are the most
>> common C string calls in rustc?)
> It isn't just C, I'm afraid. It's pretty much every other language and OS,
> too, because every language and OS is designed for C as the
> lowest-common-denominator.
>> * Each C function has its own expectations about character encoding
>> and allowed characters, so calls to C involve extra state-tracking or
>> checks anyway.
> I can't really agree. Some C functions have 'expectations about character
> encoding and allowed characters' but many don't, and those that do don't
> necessarily require 'extra state-tracking or checks' at run-time.
> It would be best if rust could hide the 'implementation detail' of
> null-termination, but for the foreseeable future, the potential interop
> performance advantages probably outweigh a byte of wasted storage here and
> there (after all, if one byte were important, we wouldn't want to use a
> whole 4 bytes to hold the string length.)
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list