--- Comment #6 from Steven Schveighoffer <> 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

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:
------- You are receiving this mail because: -------

Reply via email to