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: kenner@lab.ultra.nyu.edu (Richard Kenner)
Subject: Re: Not intended for use in medical,
Date: 1997/05/04
Message-ID: <5kho48$vgf$1@news.nyu.edu>#1/1
X-Deja-AN: 239272308
References: <dewar.862270256@merv> <5k5ifi$8db@bcrkh13.bnr.ca>
 <x7vohassedl.fsf@pogner.demon.co.uk>
Organization: New York University Ultracomputer Research Lab
Newsgroups: comp.lang.ada
Date: 1997-05-04T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <x7vohassedl.fsf@pogner.demon.co.uk> Simon Wright <simon@pogner.demon.co.uk> writes:
>kaz@vision.crest.nt.com (Kaz Kylheku) writes:
>> 	return ((x < y) && x++) && ((x < y) && x++);

>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?).

That's correct.  The statement above is invalid C and the results are
undefined since there is a use and post-incremement within the same
pair of sequence points.

However, the originally-quoted statement is perfectly valid and
well-defined because "&&" is a sequence point.

GCC was indeed generating the incorrect code for that statement.  If I
remember correctly, the fix for that bug was installed in the development
sources last week sometime.