From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Not intended for use in medical, Date: 1997/05/04 Message-ID: <5kgu95$kb7@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 239213584 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <5k5ifi$8db@bcrkh13.bnr.ca> Organization: Prism Systems Inc. Newsgroups: comp.lang.ada Date: 1997-05-04T00:00:00+00:00 List-Id: In article , Simon Wright wrote: >kaz@vision.crest.nt.com (Kaz Kylheku) writes: > >> int foo(int x, int y) >> >> { >> return ((x < y) && x++) && ((x < y) && x++); >> } [ snip ] >Hmm. I believe that writing eg > > a[i] = ++i; > >invokes undefined behaviour (is the pre- or post- value of i used for >the index operation?). Sorry about this C intrusion into comp.lang.ada. I didn't intend that example to spark a discussion about C semantics, but just to clear up, the && operator in C has sequencing properties. Its left constituent must not only be evaluated before its right, but its side effects must also be settled before the left side is evaluated. Hence x++ && x++ is perfectly well defined. The program I was writing depended on this crucial sequencing property. >While inspecting your program, I would be fairly sure of the meaning >you intended but quite unsure without checking the standard as to >whether it had entered the realm of the undefined. And I see that your >original code was _more_ complex! Crikey! The complexity was hidden behind friendly macros. :) The intent was to inline some code which performed external data encoding and decoding, having the logic ``if there is space in the buffer, add a character to it and return true, else return false''. This logic was turned into a function-like macro. The problem arose when I combined two of the macros like this: foo(..) && foo(...) The bounds check in the second case was ``optimized'' away due to the bug, allowing the buffer to be overrun by one character. That bug is there, in GCC 2.7.2., though Chris Torek rapidly came up with a an unofficial patch. :) >I would also wonder why the second ++ was there anyway, it has no >effect (unless of course x was a reference, but we're talking C here, >and then the effect of the code would be amazingly hard to understand) The example you are looking at was specially contrived to illustrate the bug, so it has no useful meaning. When reporting a compiler bug, it's quite helpful to the developers if you can contrive the smallest example which illustrates the bug.