http://d.puremagic.com/issues/show_bug.cgi?id=6175



--- Comment #6 from Steven Schveighoffer <schvei...@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: -------

Reply via email to