scope of malloc

[Jim Patterson]

In article <3739 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
>In article <14413 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>
>>>You have the choice of rejecting machines or compilers with such serious
>>>deficiencies as making alloca() impossible.
>
>>What nonsense.  Being unlike a VAX is hardly a "serious deficiency".
>
>As you know, there are plenty of machines that are quite unlike vaxes
>that implement alloca().  I think you would even agree that there are
>very few machines on which it is impossible.  So I think your comment
>is pointless.

Even alloca() on a VAX can be trouble, as I found out from direct
experience. When we first moved our products onto VAX/VMS using VAX-11
C (yes, VAX/VMS, not Ultrix or something else), we used a variant of
alloca() written in assembler (not too hard to do).  However, we found
that when we compiled our products with the /OPTIMIZE switch they
broke.  It turns out that VAX-11 C likes to address one or two words
off of the stack pointer SP since this generates shorter instructions
than frame-pointer-relative instructions for those particular
variables. By moving the stack pointer (what any typical alloca
implementation does), and not telling the compiler about it, we broke
the code.

Since /OPTIMIZE was more important for us than occasional increased
code efficiency using alloca(), we stopped using alloca(). We haven't
regretted it.

This could be fixed by a compiler-builtin, as Sun has done. We weren't
able to do this though since we don't have (and don't care to have)
the source to VAX-11 C.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:uunet!mitel!cunews!cognos!jimp        P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
NOT a Jays fan (not even a fan)            Ottawa, Ont  K1G 3Z4