Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!sumax!amc-gw!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: alloca() portability
Message-ID: <165@nazgul.UUCP>
Date: 16 Nov 90 21:52:52 GMT
References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu> <PAULB.90Nov12131357@hcx2.ssd.csd.harris.com> <s64421.658490039@zeus> <27634@mimsy.umd.edu>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 15

In article <27634@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
/There may be major correctness losses using alloca (as I wrote earlier,
/any optimizing compiler can easily produce failing object code from
/apparently-correct source code if that source code uses alloca).

You're right. I struggled with this problem for a while, until the
solution became obvious: make alloca() a 'magic' function, and have
the optimizations take it into account. I implemented this, and it
works fine (including in those cases you pointed out, and the cases
in the MSC manual where it says not to use it).

ANSI C allows other functions to be magic.

But the fact remains that if you wish to write maximally portable programs
you are better off avoiding alloca.