[Issue 6175] String corruption when passing static char arrays to std.conv
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Apr 19 08:00:13 PDT 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6175
--- Comment #6 from Steven Schveighoffer <schveiguy at yahoo.com> 2012-04-19 08:01:06 PDT ---
Interesting problem!
So here is what happens. The IFTI type determined for the statCArr argument is
char[9u], which means it's actually passed as a static array *by value*.
The first toImpl template matches and it looks like this:
/**
If the source type is implicitly convertible to the target type, $(D
to) simply performs the implicit conversion.
*/
T toImpl(T, S)(S value)
if (isImplicitlyConvertible!(S, T))
{
alias isUnsigned isUnsignedInt;
// Conversion from integer to integer, and changing its sign
static if (isUnsignedInt!S && isSignedInt!T && S.sizeof == T.sizeof)
{ // unsigned to signed & same size
enforce(value <= cast(S)T.max,
new ConvOverflowException("Conversion positive overflow"));
}
else static if (isSignedInt!S && isUnsignedInt!T)
{ // signed to unsigned
enforce(0 <= value,
new ConvOverflowException("Conversion negative overflow"));
}
return value;
}
Both of those static ifs fail, so it essentially boils down to this:
char[] toImpl(char[9u] value)
{
return value;
}
this means it is returning stack data! I'm surprised this is allowed to
compile, I though the compiler would disallow such obvious escaping of stack
data.
I suppose the "correct" fix is to return value.dup in this case, but I hate the
idea that the entire array is passed on the stack, seems wasteful.
Someone with better template-fu skills than me should tackle this...
BTW, what do we think the "correct" implementation *should* be? .dup the array
or return a slice of the original? I don't know if slicing is possible given
IFTI limitations.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list