Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Abstract Syntax Tree for C programs
Date: Wed, 29 May 2019 02:01:15 -0700
Organization: None to speak of
Lines: 61
Message-ID: <lnh89dskh0.fsf@kst-u.example.com>
References: <feb250dd-88d8-41d0-9c19-8376f943f9a7@googlegroups.com> <R9wFE.278441$XC1.185015@fx21.am4> <VNwFE.1605046$%SF.388088@fx15.am4> <1727e4f9-2056-4357-8572-599c46db6a88@googlegroups.com> <J9xFE.504067$Qy4.154575@fx04.am4> <17344bb7-9c96-47eb-b006-c6c2e2b8bc59@googlegroups.com> <euDFE.788146$D22.28953@fx35.am4> <97b08cce-ec5d-4052-9338-0026b5d449bf@googlegroups.com> <RgVFE.437079$a%2.308152@fx30.am4> <V8XFE.437080$a%2.167707@fx30.am4> <87sgt339na.fsf@bsb.me.uk> <m0wGE.581043$XY4.391056@fx32.am4> <80470a36-78de-417f-bc75-a7966c87b31e@googlegroups.com> <llDGE.1694806$iiB1.205828@fx08.am4> <9cbcea67-85a8-4de3-ac01-04922ba5fc74@googlegroups.com> <HBZGE.398991$iy4.303434@fx06.am4> <lnblzntma9.fsf@kst-u.example.com> <Hw8HE.541380$II6.345396@fx07.am4> <87muj6lgco.fsf@bsb.me.uk> <NAeHE.447087$Ym1.37681@fx28.am4> <qclg57$3ad$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="c6c26aab05d6bfabe3d5296c6ba02671"; logging-data="11456"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19uET4aYahTGNRRcR9lZ0wO"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:7ZT232j0Rv4Aq7FMPsoPyhnrYO4= sha1:1//qOdh/4d2L3ALNu2MB+5qGE4g=
Xref: csiph.com comp.lang.c:144089

David Brown <david.brown@hesbynett.no> writes:
[...]
> Most of what you consider "obvious errors" (taking your post with "6
> issues in f2" as a key) are not, in fact, errors in C.  They may be old
> C, or obsolescent C, and certainly they are not recommended as good
> practice - but the code itself is allowed.
[...]

There were more errors than that.

Here's the code, followed by Bart's commentary:

        a=0;
        int f2() {
            void* p=1234;
            puts("hi");
            return;
        };

    There are 6 issues here:

    (1) Implicit declaration of a's type
    (2) Old-style parameter list
    (3) Implicit conversion of int to pointer
    (4) Implicit declaration of puts
    (5) Missing return value
    (6) Extra semicolon

(1) is certainly an error in C99 or later, and I believe it's an error
in C90.

(2) Old-style parameter lists are valid in all versions of C, but are
obsolescent.

(3) A constraint violation in C99 and later.

(4) Valid in C90, a constraint violation in C99 and later.

(5) In C90, this is legal; the behavior is undefined if the caller uses
the result.  In C99 and later, this is a constraint violation.

(6) A syntax error.

So a diagnostic is required for 5 out of Bart's 6 issues.

(As always, a non-fatal warning is a valid diagnostic, and none of the
standard's requirements apply to non-conforming compilers.)

A note on the extra semicolon: In K&R1 (1978), the syntax for a
data-definition (a kind of external-definition) was:

    extern(opt) type-specifier(opt) init-declarator-list(opt) ;
    static(opt) type-specifier(opt) init-declarator-list(opt) ;

so a lone semicolon would have been (at least syntactically) valid.
That may be why gcc and some other compilers accept it by default.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */