From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin von Loewis To: rth@cygnus.com Cc: carlo@runaway.xs4all.nl, egcs-bugs@cygnus.com, pommnitz@darmstadt.gmd.de, egcs@cygnus.com Subject: Re: Further observations regarding alloca on i586-pc-linux-gnu Date: Sun, 23 Aug 1998 12:13:00 -0000 Message-id: <199808231820.UAA00204@mira.isdn.cs.tu-berlin.de> References: <199808221724.TAA14230@jolan.ppro> <19980823043600.A4080@dot.cygnus.com> X-SW-Source: 1998-08/msg00802.html > This is well known. What is not clear to me though, is whether > it is a bug in the compiler or in the test. I've tried to find documentation on the semantics of alloca in gcc, but didn't found much. The portable alloca.c says >> allocate automatically reclaimed memory and this is how most users probably see it. extend.texi says that the memory is available until the end of the function. > The test is effectively relying on the order in which arguments are > evaluated, which is wrong. No, it doesn't. It requests memory reclaimed at the end of the function. As it turns out, the compiler might overwrite the memory allocated. > Note that the exact same effect would happen if alloca was not a > builtin. No, it wouldn't. The portable alloca would not reclaim the memory until the next alloca call, and then only if the previous call was deeper on stack. > Note that if you mind sequence points like you ought, you get > correct results. The original example was using alloca as a default argument. It seems that g++ currently does not support that, an alloca call must occur as a full expression in itself, not inside a full expression. So it seems g++ should either detect this violation in alloca usage, or be fixed to support alloca in subexpressions. Regards, Martin