Date: Thu, 10 Jul 2008 20:51:17 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Daniel Gerzo <danger@FreeBSD.org> Cc: David Malone <dwmalone@maths.tcd.ie>, cvs-src@FreeBSD.org, Roman Kurakin <rik@inse.ru>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re[2]: cvs commit: src/share/man/man9 style.9 Message-ID: <20080710202921.D8518@besplex.bde.org> In-Reply-To: <753889164.20080710011045@rulez.sk> References: <200807091404.m69E4jiC075715@repoman.freebsd.org> <20080709154945.GA47824@zim.MIT.EDU> <4874FE82.5090809@localhost.inse.ru> <753889164.20080710011045@rulez.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jul 2008, Daniel Gerzo wrote: > Hello guys, > > Wednesday, July 9, 2008, 8:08:02 PM, has been written: > >>>> -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. Once again: nested function declaration != nested function. Nested function declarations are a small-s standard C misfeature older than K&R1. We considered them bad style long before the completely different gcc extension of nested function definitions existed. Style.9 said this. Now it is broken. Kernel makefiles actually enforce non-use of nested function declarations using -Werror -Wnested-externs, but most userland makefiles don't do this so the style rule is still relevant. >>>> >>> We use lots of extensions that aren't strict ANSI C. I think the Especially since ANSI C hasn't existed since it was replaced by ISO C 20 years ago. >>> 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. > > So may I leave my change in the current state, or do you guys want me > to do some additional changes? Just back it out, since it is wrong. No one would expect use of any unportable gcc feature to be normal style, and nested functions are less deserving of specific disapproval than most such features. Strictly, style.9 disallows (by not explicitly allowing) even indispensable gcc features like asm(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080710202921.D8518>