From owner-freebsd-arch@FreeBSD.ORG Sat Jun 14 15:19:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D04B637B401 for ; Sat, 14 Jun 2003 15:19:58 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3796F43FB1 for ; Sat, 14 Jun 2003 15:19:58 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id ECD88530E; Sun, 15 Jun 2003 00:19:56 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@FreeBSD.org References: <20030614200407.GA31706@HAL9000.homeunix.com> From: Dag-Erling Smorgrav Date: Sun, 15 Jun 2003 00:19:56 +0200 In-Reply-To: <20030614200407.GA31706@HAL9000.homeunix.com> (David Schultz's message of "Sat, 14 Jun 2003 13:04:07 -0700") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: unbreaking alloca X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 22:19:59 -0000 David Schultz 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