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, 05 Jun 2019 12:52:40 -0700
Organization: None to speak of
Lines: 31
Message-ID: <lnef47vmgn.fsf@kst-u.example.com>
References: <feb250dd-88d8-41d0-9c19-8376f943f9a7@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> <qd5mna$sas$1@dont-email.me> <lnwoi1m3j3.fsf@kst-u.example.com> <qd7rg7$bcm$1@dont-email.me> <lnimtjvobw.fsf@kst-u.example.com> <qd94f4$kf6$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="2e5690e26a3a02612d58fbc15f6a6031"; logging-data="32232"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/lyRf5gpR+H1tk3gIAeiRi"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:FwHpGKYBXMWA/c/QO7w49hhbWc0= sha1:jCYHEdEPQ0sesfH56d9n42/ZW4c=
Xref: csiph.com comp.lang.c:144496

David Brown <david.brown@hesbynett.no> writes:
> On 05/06/2019 21:12, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> You are assuming that the implementation of "fn" is written in C.
>> 
>> I am not.  If the implementation of fn is not written in C, then its
>> behavior is not defined by the C standard.  That's undefined behavior.
>
> Isn't the behaviour of the C code here defined, even if the behaviour of 
> the program as a whole is not defined (by the C standards) ?  Following 
> your logic, any C code would have undefined behaviour if it calls a 
> function defined in assembly or anything other than C (except perhaps 
> standard library functions, since their behaviour is defined in the 
> standards).

That's what I'm saying, yes.

Undefined behavior is "behavior, upon use of a nonportable or
erroneous program construct or of erroneous data, for which this
International Standard imposes no requirements".  What requirements
does the C standard impose on code written in languages other
than C?  None.

Remember, "undefined behavior" doesn't mean "this code will crash"
or "this code is not useful.  It means ... well, see above.

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