From owner-svn-src-head@FreeBSD.ORG Sun Feb 15 07:38:55 2015 Return-Path: Delivered-To: svn-src-head@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 A7FC6E29; Sun, 15 Feb 2015 07:38:55 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 668D3664; Sun, 15 Feb 2015 07:38:54 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id E8DCC10455B8; Sun, 15 Feb 2015 18:38:46 +1100 (AEDT) Date: Sun, 15 Feb 2015 18:38:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans Subject: Re: svn commit: r278737 - head/usr.sbin/flowctl In-Reply-To: <20150215162553.L977@besplex.bde.org> Message-ID: <20150215182110.C1367@besplex.bde.org> References: <201502132357.t1DNvKda075915@svn.freebsd.org> <20150214193210.N945@besplex.bde.org> <20150214181508.GL15484@FreeBSD.org> <1423938828.80968.148.camel@freebsd.org> <54DFA7CC.20305@FreeBSD.org> <20150215162553.L977@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=baJSDo/B c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=ePpomapnhtmqcGUZwNAA:9 a=CjuIK1q_8ugA:10 Cc: src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Pedro Giffuni , Gleb Smirnoff , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 07:38:55 -0000 On Sun, 15 Feb 2015, Bruce Evans wrote: > On Sat, 14 Feb 2015, Pedro Giffuni wrote: >> _____ >> ... >> BUGS >> The alloca() function is machine and compiler dependent; its use is dis- >> couraged. > > This became out of date with VLAs in C99. Except for scopes, compilers > must have slightly more complications to support VLAs than alloca(). > They might still not support alloca(). But FreeBSD never used ones that > don't. That it would never use them was not so clear when this man page > was written. I found this interesting related problem on the web: inline functions with alloca() in them may blow out the stack. But this is only with broken compilers. For inline functions to work, they must have the same semantics as when they aren't inlined, especially when they are automatically inlined. This means that any alloca()'ed space in an inline function must be freed at the end of that function, not at the end of its caller. clang handles this correctly by doing requested inlining, and freeing in the right place. gcc documents the problem and normally refuse to do requested inlining in functions that call alloca(). However, gcc can be broken by forcing the inlining using __always_inline. gcc-4.2 silently produces the stack-blowing code. gcc-4.8 warns that the forced inlining might be wrong. alloca() in any macro would have this problem, unlike a [VL]A in a compound statement in a macro. Bruce