toStringz and toUTFz potentially unsafe

Jonathan M Davis jmdavisProg at gmx.com
Mon Jul 25 09:17:22 PDT 2011


On Monday 25 July 2011 09:27:34 Steven Schveighoffer wrote:
> On Sun, 24 Jul 2011 20:41:47 -0400, Johann MacDonagh
> 
> <johann.macdonagh.no at spam.gmail.com> wrote:
> > Both toStringz and toUTFz do something potentially unsafe. Both check
> > whether the character after the end of the string is NULL. If so, then
> > it simply returns a pointer to the original string.
> 
> It is of critical importance to note that this *ONLY* happens for
> immutable data.  It is not done for const or mutable strings (instead a
> zero is always appended).

That's not quite true actually. It _is_ true for toStringz, because it 
_always_ returns immutable char*, but because toUTFz has more control over the 
return type, it does it in every case where it could conceivably avoid a copy. 
So, C[] -> C*, C[] -> const C*, immutable (C)[] -> const(C)[], and 
immutable(C)[] -> immutable C* all check one past the end of the array. Now, 
the non-immutable strings probably end up appending anyway, because they don't 
get the embedded '\0' insert one past their end by the compiler, but they 
still try and avoid it. But the non-immutable strings aren't really any more 
likely to have the problem than immutable ones, since it all hinges on saving 
the returned pointer, which just isn't done normally. The only real increased 
risk is if you slice a mutable array where the first element after the slice is 
'\0', since then you could easily change it, where you couldn't if it were 
immutable, but again, you have to save the pointer, and the warning makes it 
clear that that's a situation which would be a problem.

- Jonathan M Davis


More information about the Digitalmars-d mailing list