Sometimes, the array TypeInfo.init() returns has a length, but ptr is null. Accessing an element of such an array causes segfaults. This can't be right. TypeInfo.init() should just return an empty array.
Example follows. This outputs "ptr=0000 length=4".
import std.stdio;
struct X {
int y;
}
void main() {
TypeInfo ti = typeid(X);
writefln("ptr=%s length=%s", ti.init.ptr, ti.init.length);
}
Comment #1 by schveiguy — 2011-01-07T06:46:51Z
This is really a documentation issue. The init() is correct, as I discovered when fixing a recent bug.
Essentially, when the ptr is null, but the length is non-zero, the meaning is that the init value for that type is init().length bytes of zero. This cuts down on having to store an array of zeros in the binary.
The documentation for init() says:
"Return default initializer, null if default initialize to 0"
Which seems to indicate init() should return null if default initializer should be zero. But a null array has length == 0.
I think the right solution to this is to change the documentation:
"Return default initializer. If the type should be initialized to all zeros, an array with a null ptr and a length equal to the type size will be returned"
Sound good?
Comment #2 by bugzilla — 2011-04-05T11:31:07Z
This is deliberate, see the typinf.c code:
// void[] init;
dtsize_t(pdt, sd->structsize); // init.length
if (sd->zeroInit)
dtsize_t(pdt, 0); // NULL for 0 initialization
else
dtxoff(pdt, sd->toInitializer(), 0, TYnptr); // init.ptr
I'll fix the documentation.