From owner-cvs-src@FreeBSD.ORG Wed Jul 9 18:30:55 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30D81065785; Wed, 9 Jul 2008 18:30:55 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 884538FC21; Wed, 9 Jul 2008 18:30:55 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id DB49133C51; Wed, 9 Jul 2008 22:14:10 +0400 (MSD) Message-ID: <4874FE82.5090809@localhost.inse.ru> Date: Wed, 09 Jul 2008 22:08:02 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Daniel Gerzo , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200807091404.m69E4jiC075715@repoman.freebsd.org> <20080709154945.GA47824@zim.MIT.EDU> In-Reply-To: <20080709154945.GA47824@zim.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: cvs commit: src/share/man/man9 style.9 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2008 18:30:55 -0000 David Schultz wrote: > On Wed, Jul 09, 2008, Daniel Gerzo wrote: > >> -Do not declare functions inside other functions; ANSI C says that >> -such declarations have file scope regardless of the nesting of the >> -declaration. >> -Hiding file declarations in what appears to be a local >> -scope is undesirable and will elicit complaints from a good compiler. >> +Do not declare functions inside other functions; nested functions are >> +a GCC extension and are not permitted by ANSI C. >> > > We use lots of extensions that aren't strict ANSI C. I think the > real reason not to use them is that gcc's nested functions are > particularly unwieldily. First, they're not true lexical closures > (and can't be), which makes them much less useful. Second, they > are unsupported unless a number of assumptions are met, e.g., must > have an executable stack, must be able to invalidate the I cache > from userland, and must not have separate I and D address spaces. > Nested functions abominable enough that Apple disabled the feature > in OS X's build of gcc --- and the Sun and Intel compilers don't > support them, even though Intel claims nearly complete gcc > compatibility. > I think from non-technical side, nested functions are not expected by most programmers. From my point of view there are many new extensions that a good for quick hacking, but not for the production code. rik