From owner-svn-src-all@FreeBSD.ORG Sat Feb 14 20:00:00 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8BE5508 for ; Sat, 14 Feb 2015 20:00:00 +0000 (UTC) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51771E1D for ; Sat, 14 Feb 2015 20:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423943615; bh=P/VRe0WNcfdKswkuKcSBu3P2dJBNoC45UJvkuYvZlq8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=kVcDHGoTf2y1HI8uO8EO5BZALVa6jkTTeFxs7J+HCfTR8YWpPsIbm9nYK0Xqh+GoVLBw55n7Tg3hzFHhdlQ83HP+JeSIT27ODuLgAcE8mJKnN7MLmuCzCHWCYZS0owKSjWXLr0m8KcVElpeTOU69XmpN8Dpyn3Sj6cFT6ZUR3wxf7zHGVe4luZPea4bmhciKttXTadHCP5V6SaM0Vs/HIYWHhMT6J3wQ+PQByicr6hhSXOst43rI3RpftDsvdKRRB+x9Rr4WGquyqi1BdUu6rEUtpsh7x1INz9xNgdvCK2Xo/wguL56i53vDygv9jz4Qz8Ue6ScyFFCE+63Msp4AUQ== Received: from [98.139.215.143] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2015 19:53:35 -0000 Received: from [98.139.211.193] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2015 19:53:35 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 14 Feb 2015 19:53:35 -0000 X-Yahoo-Newman-Id: 110902.27848.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Lr_6tcYVM1kaD7hfE0412MM1Vgpfv_Yn3W5X_eB3zFtGqhb 7z9vxqDnYAiqn6fuvNWRwjELmM56.8R8w4tB7mLTGpVc9onpqAHCrRsSWKWS pGAD.3ICP1mcXDNU5Oi.gUY4xFV7Ak7_0emNZkGlB3IwTphyamuba4lKqqML hbPD3uu7z0tqTxe1qnckm4wLePgJLXPfSY4fZJ.j22bFzqIEhsQ7DmjYVP_b LpKCTkGW3aQ0iEHTuNupdPt1vUEmAZmB_MJ3mH3Ee9pM9nVr0f1R16bFfqWE b5fk_z3f2jDWsNDr9s2eRTVqxqjRq.OoCVcxadGNJwa0PLqc_uqg5SdBVmnf eKpFaqwX..jBhCCdaTYtGVvV7St6j6.pT3LnN.Ubw3332mqLqiwRoAvrEPlH tulvTxqSLLD9H9vg6iHfA_h6BWdz5pRaReMtaOYggYGx_kUQcLoigo3tUt6j UqShRk.Wd.e.ByeRVc_zhI83Rxh.q2rB66VhKKFwkzs0Eux916hTgMy8GS5C EhK3ywGQ5BHbTUqj9QndfJmmoN6hNat9D X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <54DFA7CC.20305@FreeBSD.org> Date: Sat, 14 Feb 2015 14:53:48 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ian Lepore , Gleb Smirnoff Subject: Re: svn commit: r278737 - head/usr.sbin/flowctl References: <201502132357.t1DNvKda075915@svn.freebsd.org> <20150214193210.N945@besplex.bde.org> <20150214181508.GL15484@FreeBSD.org> <1423938828.80968.148.camel@freebsd.org> In-Reply-To: <1423938828.80968.148.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 20:00:00 -0000 On 02/14/15 13:33, Ian Lepore wrote: > On Sat, 2015-02-14 at 21:15 +0300, Gleb Smirnoff wrote: >> Bruce, >> >> On Sat, Feb 14, 2015 at 08:46:58PM +1100, Bruce Evans wrote: >> B> Using VLAs and also the C99 feature of declarations anwhere, and extensions >> B> like __aligned(), we can almost implement a full alloca() using the fixed >> B> version of this change: >> B> >> B> /* >> B> * XXX need extended statement-expression so that __buf doesn't go out >> B> * of scope after the right brace. >> B> */ >> B> #define my_alloca(n) __extension__ ({ >> B> /* XXX need unique name. */ \ >> B> char __buf[__roundup2((n), MUMBLE)] __aligned(MUMBLE); \ >> B> \ >> B> (void *)__buf; \ >> B> }) >> >> I like this idea. But would this exact code work? The life of >> __buf is limited by the code block, and we exit the block >> immediately. Wouldn't the allocation be overwritten if we >> enter any function or block later? >> > Why put any effort into avoiding alloca() in the first place? Is it > inefficient on some platforms? On arm it's like 5 instructions, it just > adjusts the size to keep the stack dword-aligned and subtracts the > result from sp, done. Because it's non-standard and the alloca(3) man page discourages it: _____ ... BUGS The alloca() function is machine and compiler dependent; its use is dis- couraged. ____ It is not disappearing anytime soon though, some even say the man page is wrong. Pedro.