Bug 310 – Code compiled by dmd dies without explanation / exception. Code is attached.

I found that when I was defining a bug 309. Here is the code: import std.boxer; import std.stdio; interface A { public char[] message(); } class B : A { char []info; this(char []info){ this.info = info; } public char[] toString(){ return info; } public char[] message(){ return toString(); } } void main(char [][]args){ A aa = new B( "I am A" ); B bb = new B( "I am A too!"); Box a = box( aa ), b = box( bb ); if( unboxable!(A)( a ) ) writefln( "a is A! It says: "~a.toString() ); else writefln( "a is not A! Despite it says: "~a.toString() ); if( unboxable!(A)( b ) ) writefln( "b is A! It says: "~b.toString() ); else writefln( "b is not A! Despite it says: "~b.toString() ); } Here is command lines: > dmd -I/usr/local/dmd/src/phobos TestBoxError.d std/boxer.d gcc TestBoxError.o boxer.o -o TestBoxError -m32 -lphobos -lpthread -lm Process dmd exited with code 0 > ./TestBoxError Process TestBoxError exited with code 139 The reason is that interface A does not has toString() defined ? The bug is connected with 309, I think. It is not severe - workaround is obvious - especially taking in consideration 309. GDC behaves differently: > gdc -I/usr/local/dmd/src/phobos TestBoxError.d std/boxer.d std/boxer.d:279: function std.format.doFormat (void delegate(dchar),TypeInfo[],char*,void*) does not match argument types (void delegate(dchar),TypeInfo[2],void[]) std/boxer.d:279: cannot implicitly convert expression (args) of type void[] to char* Process gdc exited with code 1 But: > gdc -I/usr/local/dmd/src/phobos TestBoxError.d Process gdc exited with code 0 >./a.out Process a.out exited with code 139 What is confusing as well. The bug is REALLY confusing, especially for Java programmers, because we know well, that EVERY object has toString. I think that this bug can be relevant to std.format.doFormat or to the way how dmd handles interfaces.

If main() returns a void, as it does in the example, it will have garbage for the exit code, which is what you're seeing.

This was fixed in 0.175 or earlier.