🚀 go-pugleaf

In article <1992Oct13.011303.27314@nntpd.lkg.dec.com> diamond@jit.dec.com (Norman Diamond) spreads misinformation:
>In article <1bcn2mINN680@news.aero.org> lmiller@aero.org (Lawrence H. Miller) writes:
>>If I have a static function defined in a file, must the 
>>prototype also have the word static?
>
>The first prototype with file scope must say "static."

This was correct.

>All prototypes with block scope that appear before the first prototype with
>file scope must also say "static."

This was wrong.  As two people have pointed out by e-mail, ANSI 3.5.1
prohibits this.  However, the prohibition is in a Semantics paragraph, so
no diagnostic is required, and friendly implementations are allowed to
either do the right thing or nuke the ANSI C committee :-)

In fact, no prototypes with block scope may precede the first prototype with
file scope.

>After the first prototype with file scope, later prototypes may either say
>"static" or "extern" or may omit the storage class entirely.  Reasons:

Later prototypes that also have file scope have all of these freedoms.
Later prototypes with block scope may say "extern" or omit the storage class.
Reasons are still the same:

>ANSI 3.1.2.2, page 22 lines 16 to 18:  "If the declaration of an identifier
>for an object or function contains the storage-class specifier extern, the
>identifier has the same linkage as any visible declaration of the identifier
>with file scope."  So it retains internal linkage from the first file scope
>declaration, even if it says "extern" this time.
>
>Same page, lines 20 to 21:  "If the declaration of an identifier for a
>function has no storage-class specifier, its linkage is determined exactly
>as if it were declared with the storage class specifier extern."  So by
>this roundabout method, it again retains internal linkage.

>>My reading of the standard is that the word static is forbidden in block
>>scope declarations, but gnu C requires it.

Yeah, if gnu C requires it, it's wrong.  But maybe you have an old version.

>In article <bjEsPb0L@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>>I can't reproduce the problem that you describe.  Given the program
>>	void f(void) { static void g(void); g(); }
>>	static void g(void) {}
>>`gcc -ansi -pedantic' (GCC 2.2.2) issues a diagnostic, as required by
>>the C standard

Nope, still not required, just permitted :-)

>>The proper way to write this is:
>>	static void g(void);
>>	void f(void) { g(); }
>>	static void g(void) {}

Yup.

>>The GCC manual says:
>>     Some users try to use `-pedantic' to check programs for strict ANSI
>>     C conformance.  They soon find that it does not do quite what they
>>     want: it finds some non-ANSI practices, but not all--only those
>>     for which ANSI C *requires* a diagnostic.
>
>Nope, it found a practice for which ANSI C doesn't require a diagnostic

but only *allows* a diagnostic.  Considering that ANSI C always allows
spurious diagnostics regardless of anything, the GCC manual's wording
should be changed, but I'm not quite sure what to.

Demand a refund for your copy of the GCC manual :-)
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."