http://d.puremagic.com/issues/show_bug.cgi?id=6175
--- Comment #6 from Steven Schveighoffer <[email protected]> 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: -------
