Should Wine use alloca or not?
ps at leissner.se
Mon Feb 12 11:03:05 CST 2001
> > So perhaps we should debate whether we should use alloca or not.
> I'll throw my reasons in:
> -alloca with unknown length argument resolves to a function
> call, so isn't as
> effiecient as just moving the stack pointer.
It does? Even on x86? Why?
I'm certainly not an expert on this,
but AFAIK you can just dynamically move
the stack pointer (SP) register, the base
pointer (BP) register will know where the
stack frame of the function is anyway.
> -it does not fail gracefully, it segfaults (according to the
> gcc docs).
That is the problem of all cases of runs out of stack.
Of course if you allow allocations of more than one page
you must have multiple guard pages, but then one page
allocation should be enough for most uses in Wine.
the same problem.
> -Its not available on all platforms
True, but does any intresting platform for Wine lack it?
> -Over/underwriting stack memory leads to very hard to debug problems
> (corrupted stack). Dynamic memory may catch this with page protection.
Sure, but the "char buffer[10*PAGE_SIZE]" have the same problem haven't it?
We are not talking about allocation large amounts of space anyway,
but being able to allocate a buffer for ANSI <=> UNICODE translation
on the stack would be useful and most strings are not that large.
> -It may not play well with exceptions, and even when it does,
> it slows them
> down horribly (lists of stack allocated memory must be kept
> in order to
> unwind the stack correctly). Where we may be mixing c++ and
> windows style
> exceptions this could be especially bothersome.
I (or you) must have missed something but, AFAIK the BP register
and not the SP register is used for unwinding. As far as C++ is concerned
nobody should expect destructors to be called of alloca:ed memory
just like it doesn't on malloc:ed memory.
> -Its easy to get it wrong when memory is allocated in a code
> block, because
> the standard says the memory can be freed at the end of the
> block or the
> function. Its easy to forget this and use the memory outside
> of the block,
> which will fail on some implementations.
Of course you must be careful with what you do.
The same goes for the "char buffer" case.
> Thats why I say 'style-wise' I don't use it (I do have real
> reasons). There
> are too many potential problems lurking there for my liking.
> I see it as an
> optimisation, if required it should be added later, commented
> and only once
> the need to use it has been demonstrated by profiling.
Well, I think for example that stack allocating buffers for
ANSI <=> UNICODE translation might be a good idea.
More information about the wine-devel