From owner-freebsd-arch@FreeBSD.ORG Sat Jun 14 13:04:15 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 3811037B401 for ; Sat, 14 Jun 2003 13:04:15 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BD1743FAF for ; Sat, 14 Jun 2003 13:04:13 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5EK496l033545; Sat, 14 Jun 2003 13:04:09 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5EK47ZX033544; Sat, 14 Jun 2003 13:04:07 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 14 Jun 2003 13:04:07 -0700 From: David Schultz To: Dag-Erling Smorgrav Message-ID: <20030614200407.GA31706@HAL9000.homeunix.com> Mail-Followup-To: Dag-Erling Smorgrav , arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: arch@FreeBSD.ORG 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 20:04:15 -0000 On Sat, Jun 14, 2003, Dag-Erling Smorgrav wrote: > David's latest commit to cdefs.h breaks the build by causing lint to > fail for every source file that directly or indirectly includes > ; it will similarly cause non-GNU compilers to fail on > the same files. This is entirely unnecessary as the patch was only > meant to add alloca(3) support on compilers that support it. > > I'd like to commit the attached patch (after suitable testing of > course). It removes all mention of alloca(3) from cdefs.h, and > instead modifies the declaration in stdlib.h so that GNU compilers see > alloca(sz) defined to __builtin_alloca(sz) while other compilers (and > linters) see a regular prototype. 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. > 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. Then again, there's virtually no software out there that uses alloca(), so if you have your heart set on it, I can hardly object to a warning that I never see.