unbreaking alloca

[Dag-Erling Smorgrav]

David Schultz <das at FreeBSD.ORG> writes:
> alloca() is, by necessity, a compiler feature.  AFAIK, you
> shouldn't need to #define alloca __builtin_alloca, since any
> compiler should be providing it if it is supported at all.  I
> think simply declaring it should be sufficient; at least this is
> the case for gcc.

Not if you build with -fno-builtin or some other option that disables
builtins.  This is precisely why -CURRENT is currently broken.

>> I would also like to add (at some future date) a link-time warning for
>> alloca(3) similar to what we already have for gets(), mktemp() etc.
> I worry a little bit about overdoing those.  The gets() and
> mktemp() warnings are there for security reasons; it's virtually
> impossible to use those functions without introducing a possibly
> security-relevant bug.  An alloca() warning would be more of a
> portability warning, which is of no interest to the end users of
> the software as long as alloca() works, and redundant if it
> doesn't work.  Security, on the other hand, *is* a concern to end
> users.

I think you misunderstand.  If we actually reference an alloca symbol
in libc (which is what it would take to trigger the warning), the
program is broken since that alloca is guaranteed not to work.  If
we're using the builtin alloca, the call will expand inline and the
warning will never be triggered.

DES
-- 
Dag-Erling Smorgrav - des at ofug.org