Biggest problems w/ D - strings

[Regan Heath]

Vladimir Panteleev wrote:
> On Sat, 11 Aug 2007 00:49:01 +0300, C. Dunn <cdunn2001 at gmail.com>
> wrote:
> 
>> I have a field of n chars stored on disk.  It holds a
>> null-terminated string, padded with zeroes.  It is amazingly
>> difficult to compare such a char[n] with some other char[] (which,
>> by the dictates of D, may or may not be null-terminated).
> 
> This reminds me of the Delphi string problem. Before Delphi 3 (OSLT),
> you had to do crazy stuff to get a PChar (char*) out of a string.
> Delphi "long" strings are somewhat similar to D's strings - they have
> a length property, and allow the string to contain zeroes. Because of
> that, you couldn't just typecast a string to a PChar, due to lack of
> a terminating zero. Borland solved the problem by having strings
> always have a null terminating byte at their end, thus allowing you
> to typecast a string directly to a PChar.
> 
> I noticed that memory for arrays are always allocated with an extra
> byte (internal/gc/gc.d, function _d_arraysetlengthT). I wonder if
> this is related and can be used for this purpose..?

It could but the problem remains when dealing with slices, eg.

string foo = "this is a test";
string bar = foo[5..9];

the byte following the end of the slice 'bar' is ' ' not '\0'.

I believe there was/is a hack in toStringz which checks the byte 
following the slice and if it's '\0' already, does nothing but return 
the input string.

Regan