cvs commit: src/share/mk bsd.sys.mk

[Tim Robbins]

On Sat, Jun 14, 2003 at 12:01:35AM -0700, Peter Wemm wrote:

> Tim Robbins wrote:
> > On Sat, Jun 14, 2003 at 12:39:33AM +0200, Dag-Erling Smorgrav wrote:
> > 
> > > Peter Wemm <peter at FreeBSD.org> writes:
> > > >   Log:
> > > >   We cannot use c99 on amd64 either due to lack of alloca().  libc:strpti
>     me()
> > > >   uses alloca() and alloca is impossible to implement as a callable funct
>     ion
> > > >   on amd64.  It has to be a compiler builtin.  Note that the bigger probl
>     em
> > > >   is that libc is not c99 clean internally.
> > > 
> > > #define alloca(sz) __builtin_alloca(sz)
> > 
> > That would be fine in the __GNUC__ >= 2 && __BSD_VISIBLE case.
> > 
> > For the other cases, I think we should also take the alloca() implementation
> > from contrib/amd/libamu/alloca.c and throw out lib/libc/i386/gen/alloca.S.
> > That way we get GCC's fast and conventional alloca() implementation for
> > !CSTD=c?9 programs, and a slower alloca() that uses the heap and sometimes
> > leaks memory for CSTD=c?9 programs (and programs that are compiled with
> > non-GCC compilers without their own alloca() implementation).
> 
> We really really dont want to use that alloca.c except as an absolute last
> resort.  I mean Really.  It is Nasty.  I would rather that we removed alloca()
> entirely from the tree rather than use alloca.c by default for any of our
> released platforms.

I agree that it's very nasty because it will create memory leaks that are
difficult to track down. I don't want any platform to use alloca.c by default,
I just thought it might be useful in case someone compiles with -std=c?9 then
#undef's alloca, or uses (alloca)(x) instead of alloca(x).


Tim