Patrik Stridvall ps@leissner.se writes:
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.
If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems.
On 12 Feb 2001, Alexandre Julliard wrote:
Patrik Stridvall ps@leissner.se writes:
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.
If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems.
Last time this came up, someone had found the stack overflowing with a large allocation - something like the char foo[10*1024] Patrik mentions - and moved it to malloc(). At which point, someone else suggested turning the malloc() into an alloca(), since it's faster...
At the time, there were some fairly tight stack constraints in places. Have these disappeared, or is alloca() still the wrong thing to do???
James.
-
Alexandre Julliard -
James Sutherland