http://d.puremagic.com/issues/show_bug.cgi?id=10589
--- Comment #2 from monarchdo...@gmail.com 2013-07-12 14:29:45 PDT --- (In reply to comment #1) > I think you are mixing two levels of abstractions here: > > ubyte* p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE); > ubyte[] s = p[0 .. 0]; > writefln("%6s: s.capacity is %6s", i, s.capacity); > > GC.malloc requests raw memory from the GC. capacity is a function very > specific > to the way arrays are implemented on top of it in rt/lifetime.d. It assumes > that any allocation with bit APPENDABLE set and that is larger than a page of > 4kB reserves 16 bytes at the start of the allocation to store the actually > used > length of the memory. > So, to create an empty array manually that works with capacity, you'd have to > set s to > > auto start = i <= 2048 ? 0 : 16; > ubyte[] s = p[start .. start]; Hum. That worked. Is the memory layout for the APPENDABLE data documented somewhere, or are these just reverse-engineered magic numbers? > and you'd better clean that full memory block first to avoid the length field > containing garbage. Nope (I think). Length is carried in the slice, not the block. Block only contains capacity/used info. ------------------------------------------------------------------------ Thank you for your answer. I suppose the behavior isn't going to change. Still, this requires more support. I think APPENDABLE should be better documented. In particular, the magic numbers should be user accessible via manifest constants, or functions, so as to not have to guess/reverse engineer them. This is what I've discovered: 0 - 256 bytes: 1 Byte APPENDABLE info at end; Capacity = memory size - 1; 257 - 2048 bytes: 2 Byte APPENDABLE info at end; Capacity = memory size - 2; 2049 - **** bytes: 16 Byte APPENDABLE info at beginning; 1 Byte unknown info at end; Capacity = memory size - 17; Are these numbers platform depending? What the heck is that 1 byte that leads to 17 byte difference I'm seeing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------