Date: Thu, 10 Jul 2008 13:19:14 +0400 From: Roman Kurakin <rik@inse.ru> To: Daniel Gerzo <danger@FreeBSD.org> Cc: David Malone <dwmalone@maths.tcd.ie>, cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/share/man/man9 style.9 Message-ID: <4875D412.1040304@localhost.inse.ru> 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
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. >>>> >>>> >>> 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. >> > > So may I leave my change in the current state, or do you guys want me > to do some additional changes? > IMHO "are not permitted by ANSI" is not secure enough in case ANSI will release a new edition. And some one may say "hey it is permitted by ANSI now, let start using it". rik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4875D412.1040304>