[Issue 8580] New: VariantN.peek works wrongly for types with size bigger than maxDataSize template argument
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Aug 23 16:31:55 PDT 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8580
Summary: VariantN.peek works wrongly for types with size bigger
than maxDataSize template argument
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: cybevnm at gmail.com
--- Comment #0 from cybevnm <cybevnm at gmail.com> 2012-08-23 16:31:48 PDT ---
Consider the code:
import std.stdio;
import std.variant;
struct S(size_t BuffLen)
{
ubyte[BuffLen] arr;
}
void fill(T)(ref T val)
{
foreach(ref item; val.arr)
{
item = 0xff;
}
}
void printFewBytes(T)(T val)
{
foreach(i; 0..10)
{
writef("%02X ", val.arr[ i ]);
}
writeln();
}
// for 64 bit linux maxDataSize is 32 bytes
void main()
{
// case when user type fits directly in Variant's storage
{
S!(32) s; // structure with specified size
fill(s); // fill structure with some recognizable pattern (0xFF in our
case)
auto v = Variant(s);
printFewBytes(*v.peek!(S!(32))());
}
// case when user type bigger than Variant's storage
{
S!(33) s;
fill(s);
auto v = Variant(s);
printFewBytes(*v.peek!(S!(33))());
}
}
Output:
FF FF FF FF FF FF FF FF FF FF
80 FF 02 33 4E 7F 00 00 00 00
For structure with size smaller than Variant's storage we have expected output,
in second case we seeing some random bytes, which actually are address of
dynamically allocated by Variant's implementation object.
Some fragments of variant implementation:
// part of Variant.opAssign, where pointer saved to storage
...
auto p = new T;
*p = rhs;
memcpy(&store, &p, p.sizeof);
...
// part of Variant.peek where storage erroneously interpreted as type's
instance bytes
...
return type == typeid(T) ? cast(T*) &store : null;
...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list