1000 – writefln fails on nested arrays

D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 1000 - writefln fails on nested arrays
Summary: writefln fails on nested arrays
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D1 (retired)
Hardware: x86 Windows
: P2 normal
Assignee: Walter Bright
URL:
Keywords:
Depends on:
Blocks:
Reported: 2007年02月22日 23:12 UTC by Bill Baxter
Modified: 2014年02月16日 15:23 UTC (History)
0 users

See Also:


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Bill Baxter 2007年02月22日 23:12:19 UTC
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
}
Comment 1 David Freitas 2007年03月25日 12:15:32 UTC
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?
"
Comment 2 Walter Bright 2007年04月27日 14:56:27 UTC
Fixed DMD 1.014


AltStyle によって変換されたページ (->オリジナル) /