Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Abstract Syntax Tree for C programs Date: Sun, 26 May 2019 14:18:27 -0700 Organization: None to speak of Lines: 74 Message-ID: References: <1727e4f9-2056-4357-8572-599c46db6a88@googlegroups.com> <17344bb7-9c96-47eb-b006-c6c2e2b8bc59@googlegroups.com> <97b08cce-ec5d-4052-9338-0026b5d449bf@googlegroups.com> <87sgt339na.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bd49e134f673f0f04f4092253526d6c8"; logging-data="22525"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cEaQwKfj1zV4iCV8ESnEo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:+4U3UbdX4Ix9zBD9eczJq9U+mqM= sha1:JA/Qk4o7BIQcDsttMRe0N+q9hwQ= Xref: csiph.com comp.lang.c:144029 Bart writes: > On 26/05/2019 20:42, Keith Thompson wrote: >> Bart writes: >>> void F(void){}; >>> void G(void){}; >>> >>> I had quite a bit of trouble getting any compiler to notice the >>> semicolons. At best I could get clang or gcc to produce a warning. >> >> Take a look at the grammar. A lone semicolon inside a block is >> a "null statement". (It's a bit odd that a null statement is >> considered to be a kind of expression statement, but that's what >> the standard says.) >> >> Outside a block, at file scope, statements are not permitted, and >> there's no such thing as a null declaration. The extra semicolon >> is a syntax error. > > At file scope, you also have ordinary declarations as well, and they > need to be terminated with semicolons, including the ones that end > with "}". But function definitions that end with "}" don't. Exactly. I think your point, as always, is that you don't like the way it's defined. Sometimes a semicolon is required after a closing curly brace, sometimes it's optional, sometimes it's forbidden. All die, O the embarrassment. >> Many C compilers permit (and ignore) null declarations at file >> scope as an extension. >> >> I'm not surprised that you had trouble getting compilers to complain >> about the semicolons. In spite of being told many times, you pretend >> not to remember that with gcc and clang, you need to use something >> like "-std=c11 -pedantic" to enforce all the language rules, or >> "-std=c11 -pedantic-errors" to treat violations as fatal errors. > > I actually don't care. Out of 8 C compilers, none picked up on > that. Only clang and gcc could be made to notice if fed the right > options. The other six don't look like they can be made to detect that > syntax error. I'm skeptical that there are serious C compilers that can't be made to diagnose an extraneous semicolon in that context, though I can well believe that you wouldn't be able to figure out how to make them do so. If you'll identify the compilers, others here can either tell you how to make them conform, or submit bug reports. > That counts as "a bit of trouble". > >>> void F(void) {} void G(void) {} >>> >>> which doesn't look right. >> >> I agree that putting two function definitions on a single line doesn't >> look right. > > You're forgetting that C is free-format so it shouldn't matter. You accuse me of forgetting that C is free-format when that's exactly the point I was making? > As it > is, this is what C mandates: > > int A[]={1}; void F(void){} int B[]={2}; void G(void){} void H(void); > > The rule about whether it's "}" or "};" seems somewhat mandatory. Of course it's mandatory for conforming C compilers. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */