cvs commit: src/share/man/man9 style.9

[Bruce Evans]

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