Phobos for Review: std.buffer.scopebuffer

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Sat Feb 8 04:24:35 PST 2014


On Saturday, 8 February 2014 at 07:43:06 UTC, Lars T. Kyllingstad 
wrote:
> "On many systems alloca() cannot be used inside the list of 
> arguments of a function call, because the stack space reserved 
> by alloca() would appear on the stack in the middle of the 
> space for the function arguments."
>
> So... devil spawn, then?

alloca() is compiler dependent. LLVM has experimental support for 
alloca in parameters using a dedicated specification. This is the 
downside of depending on backends developed for C. For instance 
if the backend emits code that is relative to the end of the 
stack rather than the beginning of the stack frame you have to 
move down all locals whenever you call alloca():

{
BUFFER64K buffer;
auto dynarr = alloca(smallsize); // triggers a copy of 64KiB and 
fucks up all pointers to buffer
}

If you can rely on indexing relative to the beginning  of the 
stack frame you just have to change the stack pointer. If you 
insist on returns of a single dynamic sized temporary being at 
the end of the stack upon return (+whatever RET eats) you can 
just move your own stack frame, I believe.

Thus not wasting a lot of space of the caller stack frame and 
return the length, then the caller can adjust it's own stack 
pointer by adding the offset+length. And prepending to that 
dynamic array is cheap in simple function bodies, just push 
values onto the stack.

But the IR/backend must support it. C-semantics are viral… :-(


More information about the Digitalmars-d mailing list