Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: bart again (UCX64) Date: Wed, 06 Sep 2023 18:47:02 -0700 Organization: None to speak of Lines: 82 Message-ID: <87ledi3gbt.fsf@nosuchdomain.example.com> References: <878r9p7b13.fsf@nosuchdomain.example.com> <20230901175635.91@kylheku.com> <87edjeujqw.fsf@bsb.me.uk> <87tts9sbo8.fsf@bsb.me.uk> <87pm2wq8se.fsf@bsb.me.uk> <87tts7ou7x.fsf@bsb.me.uk> <87pm2u3o8i.fsf@nosuchdomain.example.com> <87cyyuq2oc.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="8a8332d09d93cf379db0c937f1be48e4"; logging-data="2989340"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qqwmtojD7oJaP26/g/fMZ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:t+JqtIeJTa9BYShya8v3cAfLWdU= sha1:3OmLbfX/gbcamf4X/epnasgZQe4= Xref: csiph.com comp.lang.c:174250 Ben Bacarisse writes: > Keith Thompson writes: >> Ben Bacarisse writes: >>> Bart writes: >> [...] >>>> I assume GNU C allows semicolons after function definitions. That's >>>> unfortunate. If the grammar rule was applied strictly, then there would be >>>> no programs in existence that would use semicolons like that. >> >> Just to be clear, a semicolon after a function definition: >> >> void foo(void) {}; >> >> isn't associated with the function definition. The semicolon is treated >> as a file-scope declaration. If the above is valid, then so is a >> source file consisting of a single line with just a semicolon. >> >>> K&R C allowed it, mainly because a type-specifier can be omitted and >>> defaults to int. The /grammar/ in K&R does not permit it, but the text >>> says that, if the type-specifier is missing it is taken to be int. >> [...] >> >> So K&R C (and C90?) treated this: > > Not C90 as far as I know. You're right. >> ; >> >> at file scope as a definition with an implicit type of int, so it's >> equivalent to this: >> >> int; > > Probably, though it's hard to tell if that is "equivalent" since there > are no observable facts. A K&R C Unix V7 compiler running on a PDP11 > simulator accepts this code silently: > > ; > int; > int main(){ return 1; }; > > K&R1 says that both the type specifier and the storage class specifier > can be omitted, and that int is assumed when no type is given. When the > storage class is missing it is assumed to be auto in a function and > extern outside, with the exception that function are never automatic. Right. What I was wondering about is which rule makes int; at file scope invalid -- and I think I've found the answer. C90 6.5 has this syntax: declaration declaration-specifiers init-declarator-list[opt] ; with this constraint: A declaration shall declare at least a declarator, a tag, or the members of an enumeration. The wording in later editions is similar. K&R1 did not have that constraint. So `int;` satisfies the syntax of a declaration, but violates the constraint. The *init-declarator-list* is optional so you can have declarations like: enum foo { x, y }; Both `enum foo { x, y }` and `int` are type specifiers; the former is allowed by itself in a declaration, but the latter is not. Getting back to the original issue, I think that gcc's acceptance of a lone semicolon at file scope goes back to K&R C, which allowed it; the old "implicit int" rule made it equivalent to `int;`, which was allowed because the constraint I mentioned above had not yet been introduced. It would IMHO have been reasonable for gcc to make this invalid by default. Of course it rejects it if you ask for conformance. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */