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: Tue, 04 Jun 2019 15:36:51 -0700
Organization: None to speak of
Lines: 61
Message-ID: <lnftopm0zg.fsf@kst-u.example.com>
References: <feb250dd-88d8-41d0-9c19-8376f943f9a7@googlegroups.com> <475067fe-369c-4246-84a1-05b1a3a0c6be@googlegroups.com> <dtRHE.433290$jo3.201774@fx10.am4> <c6328115-1268-46a7-bc5f-c3b559deb0fd@googlegroups.com> <T8VHE.599012$II6.514448@fx07.am4> <5dd4672f-a571-40bc-bb1a-c14f6c631eb7@googlegroups.com> <OR_HE.612559$Qy4.198146@fx04.am4> <ccfd7e39-8e00-449e-b8db-30c48f1a714b@googlegroups.com> <FcbJE.644503$Qy4.643379@fx04.am4> <lnimtmpifz.fsf@kst-u.example.com> <FpfJE.631268$hy5.13238@fx34.am4> <KJfJE.16484$z55.5128@fx43.iad> <JVfJE.543410$6s.184655@fx39.am4> <lny32inxkm.fsf@kst-u.example.com> <bQhJE.1089975$da5.325050@fx13.am4> <lntvd6nsv0.fsf@kst-u.example.com> <QxiJE.563640$X23.130611@fx38.am4> <8d90e6a8-097d-4573-a88a-1f5f56dda26d@googlegroups.com> <BFrJE.2517090$%SF.2396207@fx15.am4> <f9e50905-b19c-456d-86f4-22c57f3fdb42@googlegroups.com> <lna7exnk63.fsf@kst-u.example.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="2e5690e26a3a02612d58fbc15f6a6031"; logging-data="13029"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185tJ8gaeToEeZm2KYEyVfO"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:RtJ9XOPi3TuBPMlF1zy43CLG4d4= sha1:c/XifyBf/i6MSNSkI78kYyIdbeI=
Xref: csiph.com comp.lang.c:144435

Keith Thompson <kst-u@mib.org> writes:
> guinness.tony@gmail.com writes:
>> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart  wrote:
> [...]
>>> How difficult can it be? For example:
>>> 
>>>   int main (void) {
>>>      fn(1,2,3,4);
>>>      fn("hello world");
>>>   }
>>> 
>>> There are no declarations of 'fn' visible; should this code pass or 
>>> fail? Apparently gcc passes this
>>
>> So it's a valid GnuC program.  Irrelevant to a discussion in a C newsgroup.
>
> That depends on what you mean by "valid".
>
> In C90, the program has undefined behavior, because at most one
> of the two calls passes correct arguments, but no diagnostic
> is required.  It violates a constraint in C99 and later.  Recent
> versions of gcc with default options will warn about an implicit
> declaration of fn (but will not notice that the two calls are
> inconsistent).
>
> This is why C has prototypes.  Using them avoids this problem.
> (I've seen arguments that non-prototype declarations can be useful
> in some contexts, but this is not one of those contexts.)

I was able to contrive a context in which the above code has defined
behavior in C90 (but not in C99 or C11, where it's still a constraint
violation):

    $ cat fn.c
    #include <stdlib.h>
    int fn(int a, int b, int c, int d) {
        exit(0);
    }
    $ cat c.c
    int main (void) {
        fn(1,2,3,4);
        fn("hello world");
    }
    $ gcc -std=c90 -pedantic-errors fn.c c.c -o c
    $ ./c
    $

The only way to avoid undefined behavior is to prevent the second call
from being evaluated.

You could do the same thing in C99 or C11 by providing a visible
non-prototype declaration for fn:

    int fn();

Of course the real solution is: Don't do that.

-- 
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 */