www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1000] New: writefln fails on nested arrays

reply d-bugmail puremagic.com writes:

           Summary: writefln fails on nested arrays
           Product: D
           Version: 1.007
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: wbaxter gmail.com

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

Feb 22 2007
next sibling parent d-bugmail puremagic.com writes:

------- Comment #1 from jddcef gmail.com  2007-03-25 12:15 -------
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
         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

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?

Mar 25 2007
prev sibling parent d-bugmail puremagic.com writes:

bugzilla digitalmars.com changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

------- Comment #2 from bugzilla digitalmars.com  2007-04-27 14:56 -------
Fixed DMD 1.014

Apr 27 2007