Should Wine use alloca or not?

[Patrik Stridvall]

> Jon Griffiths wrote:
> > I don't know anything about the Win32 print API, but style
>
> wise I tend to
> > stay away from alloca(). It screws up exception handling
>
> because it messes
> > with the stack, and is machine dependant. Maybe
>
> LocalAlloc() would be a
> > better choice?
>
> According to the Microsoft web site, LocalAlloc is deprecated in favor
> of HeapAlloc and friends.

Yes, LocalAlloc is for 16 bit source code compabillity and shouldn't be
used by Win32 code.
> Can anyone comment on whether using alloca will mess up Wine?  (Jon's
> comment seems to imply that he avoids alloca on general principles,
> rather than for Wine-specific reasons.) Does Wine use exceptions?

Wine uses exceptions (sort of), but I don't think alloca will interfer.

IIRC the only thing alloca does on x86 is to move the stack pointer to
allocate space.

The general problem with using alloca is that not all platforms 
supports alloca, however I think all reasonable platforms that
has enough power to support Wine is likely to have it so I don't
see any real reason not to use it.

Currently Wine uses it indirectly since the files generated 
by flex/bison uses it.

That said Alexandre has at least once rejected patches from me that
used alloca, so he doesn't seem to like it. I don't remeber him
saying why though.

So perhaps we should debate whether we should use alloca or not.
Alexandre, can you explain why you have rejected patches with alloca?
Have you any better reason that better safe than sorry?
Not that it is a bad reason but still...

[Jon Griffiths]

> Yes, LocalAlloc is for 16 bit source code compabillity and shouldn't be
> used by Win32 code.

Oops, ok, HeapAlloc then :-)
> 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 not fail gracefully, it segfaults (according to the gcc docs).
-Its not available on all platforms
-Over/underwriting stack memory leads to very hard to debug problems 
(corrupted stack). Dynamic memory may catch this with page protection.
-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.
-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.

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.

Just my 2p worth...

Cheers,
Jon