Date: Sun, 15 Jun 2003 00:19:56 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: arch@FreeBSD.org Subject: Re: unbreaking alloca Message-ID: <xzp4r2s47zn.fsf@flood.ping.uio.no> In-Reply-To: <20030614200407.GA31706@HAL9000.homeunix.com> (David Schultz's message of "Sat, 14 Jun 2003 13:04:07 -0700") References: <xzp1xxw65o7.fsf@flood.ping.uio.no> <20030614200407.GA31706@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz <das@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@ofug.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp4r2s47zn.fsf>