Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jul 2008 01:10:45 +0200
From:      Daniel Gerzo <danger@FreeBSD.org>
To:        Roman Kurakin <rik@inse.ru>
Cc:        David Malone <dwmalone@maths.tcd.ie>, cvs-src@FreeBSD.ORG, Daniel Gerzo <danger@FreeBSD.ORG>, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re[2]: cvs commit: src/share/man/man9 style.9
Message-ID:  <753889164.20080710011045@rulez.sk>
In-Reply-To: <4874FE82.5090809@localhost.inse.ru>
References:  <200807091404.m69E4jiC075715@repoman.freebsd.org> <20080709154945.GA47824@zim.MIT.EDU> <4874FE82.5090809@localhost.inse.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

-- 
Best regards,
 Daniel                            mailto:danger@FreeBSD.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?753889164.20080710011045>