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/05
Message-ID: <5kl9qc$g4d@bcrkh13.bnr.ca>#1/1
X-Deja-AN: 239560085
References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com>
 <x7vohassedl.fsf@pogner.demon.co.uk> <5kgu95$kb7@bcrkh13.bnr.ca>
 <dewar.862775250@merv>
Organization: Prism Systems Inc.
Newsgroups: comp.lang.ada
Date: 1997-05-05T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.862775250@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Kaz said
>
><<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.>>
>
>  Yes, legal, but horrible. A good reminder of why Ada does NOT have
>  the ++ operator built in :-)
>
><<The complexity was hidden behind friendly macros. :)>>
>
>  How can it ever be friendly to hide a ++ in a macro, such that the
>  peculiar rules about not using more than one ++ in an expression
>  suddenly apply in a hidden manner to the macro, Ugh!

How can it ever be friendly? If you take care to use proper sequencing
operations to protect the user from the side effects, as I did. Thus the
``peculiar rules'' were taken care of. In my original macro, the quantities
that were compared and incremented were structure members. The only caveat was
that the pointer to the structure was evaluated more than once by the macro
(the same way that getc() or putc() possibly evaluate the FILE * pointer
argument more than once). In any case, these macros were for internal use.

There is a more serious snag: if someone naively did something silly like foo()
+ foo(), undefined behavior could result. Even though both constituents of the
+ contain the && sequencing operator, the + operator doesn't guarantee a
particular order of evaluation. The sequence points in both constituents are
independent, so that

    ((x < y) && x++) + ((x < y) && x++)

could, in the actual semantics, evaluate both constituents in an interleaved
fashion, perhaps even effectively merging the sequence points into one.

God I love this stuff! :)