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.
BTW, haven't void foo(void) { char buffer[10*PAGE_SIZE]; } 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.
-
Patrik Stridvall