Bug 1000 – writefln fails on nested arrays

There seems to be a problem with writefln on nested arrays. For dynamic arrays it prints some garbage. For static arrays it generates an access violation. import std.stdio; void main() { double[][] foo = [[1.0],[2.0]]; writefln(foo[0]); // --> [1] , ok writefln(foo[1]); // --> [2] , ok writefln(foo); // --> [[1],4.63919e-306] ack! writefln("%s", foo); // --> ditto double[1][2] bar; bar[0][0] = 1.0; bar[1][0] = 2.0; writefln(bar); // Error: Access violation }

Another test case that doesn't work properly: ////////////// Digital Mars D Compiler v1.009 // libphobos /////// import std.stdio; void main() { int[char] x; // Visually: = ['a':1, 'b':2] // associative array x['b'] = 123; writefln(x); // this prints out: [b:2063597568] writefln(x['b']); // this prints out: 123 } //////////// Also, there was this comment by Frits van Bommel on the mailing list at http://www.digitalmars.com/d/archives/digitalmars/D/learn/Rectangular_or_2d_associative_arrays_6958.html " Looks like it's (the value that gets inserted) << 24, or in other words the lower byte is put in the high byte, and the others are cleared. It looks like it's dependent on the key size: if the key type is changed to ushort the upper two bytes are filled with what should be the lower two bytes, and if it's a three-byte struct (with toString) the upper three bytes should be the lower three bytes and the lower byte seems to be garbage. This bug doesn't seem to affect GDC. It looks like gphobos' std.format.doFormat.formatArg.putAArray was patched to make sure access to AA internals is performed on the correct alignment boundary. This may have been done for portability reasons, but I'm guessing it also fixes this bug. Would anyone mind confirming this and submitting a bug + patch to bugzilla? "

Fixed DMD 1.014