Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!algor2.algorists.com!jeffrey
From: jeffrey@algor2.algorists.com (Jeffrey Kegler)
Newsgroups: comp.std.c
Subject: Re: No sequence points in assignment
Message-ID: <1989Sep20.072023.9254@algor2.algorists.com>
Date: 20 Sep 89 07:20:23 GMT
References: <1021@m3.mfci.UUCP> <1989Sep13.005247.20121@algor2.algorists.com> <1026@m3.mfci.UUCP> <10851@riks.csl.sony.co.jp> <1033@m3.mfci.UUCP>
Reply-To: jeffrey@algor2.UUCP (Jeffrey Kegler)
Distribution: comp
Organization: Algorists, Inc.
Lines: 51

Those without a taste for semantic nit-picking should skip the following,
which contains nothing else of value.

karzes> In article <1033@m3.mfci.UUCP> karzes@mfci.UUCP (Tom Karzes) writes:
diamond> In article <10851@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
dpANS 3.3> In article <1026@m3.mfci.UUCP> karzes@mfci.UUCP (Tom Karzes) quotes:

dpANS 3.3> Between the previous and next sequence point an object shall have
dpANS 3.3> its stored value modified at most once by the evaluation of an
dpANS 3.3> expression.  Furthermore, the prior value shall be accessed only
dpANS 3.3> to determine the value to be stored.

diamond> Even if the expression contains two assignments to the same
diamond> object?  (As did the example which led to this thread.)  Even
diamond> without the optimizer turned on, the compiler is REQUIRED to
diamond> notice and delete all but one assignment to the same object?
diamond> Wow, a non-optimizing compiler is going to have to do a lot
diamond> of alias checking in order to meet section 3.3.

karzes> This paragraph is merely describing restrictions on the side
karzes> effects a user may have in an expression.

I am glad someone besides me (Norman Diamond) had the same problem reading
those two sentences in 3.3 as I did.  They are ambiguous depending on
whether they are taken to restrict the program or the implementation.
Footnote 31 and Appendix A.6.2 make quite clear that the intention was
to restrict the program, but they are not supposed to be part of the
standard.

It is clear what the dpANS intended to say, and it seems equally clear
that what it intended to say is the only thing that makes sense.
However, I do not believe the standard here says what it intends.

dpANS 1.6> If a "shall" or "shall not" requirement that appears out of
dpANS 1.6> a constraint is violated, the behavior is undefined.  ...
dpANS 1.6> Constraints -- syntactic and semantic restrictions by the
dpANS 1.6> which the exposition of language elements is to be
dpANS 1.6> interpreted."

Are the above two sentences from 3.3 "semantic restrictions", in which
case the burden is on the implementation?  I think so.

The definition of "shall" in 1.6 here is much too hard to interpret.
I think whereever undefined behavior is allowed the standard should
explicitly say so.  This requires only an editorial effort, since
Appendix A.6.2 lists all such cases.
-- 

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090