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: Thu, 06 Jun 2019 11:56:02 -0700 Organization: None to speak of Lines: 50 Message-ID: References: <8d90e6a8-097d-4573-a88a-1f5f56dda26d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="0ad8b66ef2f1a8fe8c740ae2f33d0263"; logging-data="1082"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18oUAob8KRV/b718Zdg3TKU" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:LyjA0a1ikCOUV3NeDqDsC5xlWk4= sha1:hzNWTzJe70RoGom26MAUdLIV4WM= Xref: csiph.com comp.lang.c:144538 David Brown writes: > On 05/06/2019 21:52, Keith Thompson wrote: [...] >> 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. > > Yes, I know that's what it means. Sometimes, however, I think it is > important to make it clear when we are talking about "behaviour that is > not defined by the C standard" (the default interpretation for > "undefined behaviour" in c.l.c.) and "behaviour that is not defined > /anywhere/" (i.e., could crash, launch nasal demons, work as the > programmer want, or anything else). And we also need to distinguish > between "this bit of the program has defined behaviour, assuming the > rest of the program is well behaved" and "since we don't know everything > about the program, we don't know if this is defined behaviour". > > Otherwise we could end up in pointless discussions about potential > undefined behaviour, whenever code calls external functions. > > So I do understand what you mean here, and I see that you are > technically correct - I am just not convinced it is a helpful viewpoint > (at least, not often helpful). Feel feel to clarify that some instance of undefined behavior is (potentially) harmless or useful. But the phrase "undefined behavior" means what it means. Remember, the particular example we're talking about: int main (void) { fn(1,2,3,4); fn("hello world"); } almost certainly has undefined behavior in C90, and violates a constraint in C99 and C11. The most meaningful thing I can say about that example is that it's bad code. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */