Re: [C, C++] "(a=b) = c;" Illegal or Undefined?

From: Jerry Coffin (jcoffin_at_taeus.com)
Date: 01/28/04 

Date: Wed, 28 Jan 2004 02:30:17 -0700

In article <Pine.LNX.4.58-035.0401271646190.15440
@unix48.andrew.cmu.edu>, ajo@nospam.andrew.cmu.edu says...

[ ... ]

> > We have NONE that determines the order of evaluation between the two
> > assignments.
>
> Yes, we do. The first assignment "*p = c;" happens *before* the
> return from f', and the second assignment "*(...)='B';" happens
> *after* the return from 'f'.

What part of the standard says that the second assignment happens after
the return from f? I've read and reread the applicable sections, and
can't find anything that even hints at such a thing.

> The assignments happen in chronological order, which is a linear
> ordering on the set of events that happen. Since the first assignment
> happens before "return p;", and "return p;" happens before the second
> assignment, we may conclude (from the transitivity property of linear
> orderings) that the first assignment happens before the second
> assignment. Q.E.D.

No -- this is just the same as something like:

i = ++i;

You can argue until you're blue in the face that the ++i has to be
evaluated before the assignment, and from a logical viewpoint that's
basically true. For better or worse, however, the standard disagrees.
 
> > > Thus we have, in this order:
> > > Call f.
> > > Assign 'A' to *p.
> > > Return p.
> > > Assign 'B' to *p.
> > >
> > > All perfectly well-defined, in both languages.
> >
> > OR we have:
> >
> > assign 'B' to *p
> > call f
>
> No, this ordering is patently impossible. You might as well say
> that we could have
>
> assign 'B' to *p
> assign 'A' to *p
> call f

Not true -- the ordering I gave is entirely possible, because the
standard doesn't specify a sequence point that prevents it. The
ordering you've given IS prevented by the sequence points specified in
the standard.
 
> The Standard explicitly tells us where the sequence points in this
> code are, and those sequence points prohibit your hypothetical
> implementation from re-arranging the code in these ways.

No, they don't. They say nothing about the relative order in which the
two assignments will be evaluated.
 
> > The sequence points are enough to determine that, in essence, the
> > assignment operator (or any other function) runs atomically.
>
> The C Standard does not define "atomically" except in the context
> of operations on sig_atomic_t, which is fairly obscure and IMHO
> not relevant to this discussion. <OT> And no, it's perfectly possible
> for an assignment operation (e.g., a structure assignment) to be
> interrupted by a signal or interrupt on all systems with which I
> am familiar. </OT>

First of all, since we're discussing overloaded operators, the C++
standard is the one that applies, not the C standard. Second, though it
doesn't use the term "atomically", the C++ standard guarantees that
(code will act as if) during the evaluation of one function, that other
code is not executed. I.e. code from one function will not act as if
its execution is interleaved with code from another function. This
prevents the ordering you've given above from being used. It does not,
however, specify anything about the relative order in which the
assignments must take place.
 

[ ... ]

> Yes, they are. That's what sequence points *do* -- they impose
> sequence on a set of events in the program. Are you *surprised* that
> the Standard requires this code to behave in the expected fashion? :-/

Having reread the applicable portions of the standard several times over
the last couple of days, I'll be more than surprised if you can actually
cite part of the standard that makes any such requirement. The standard
specifies some sequence points, but they're simply not adequate to
produce defined behavior for this code. 

-- 
    Later,
    Jerry.
The universe is a figment of its own imagination.

Relevant Pages

  • Re: C header files--Urgent
    ... an "impossible assignment" for you. ... compiler from unix to windows and compiler is written partially in c ... If they are standard header files then ...
    (comp.lang.c)
  • Re: [C, C++] "(a=b) = c;" Illegal or Undefined?
    ... Copying to the caller is a sequence point, so the assignment ... For better or worse, however, the standard disagrees. ... > during the evaluation of one function, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: which tutorial to use?
    ... Richard Heathfield writes: ... doesn't use it (except for rare examples or footnotes). ... The 42 is on the left side of an assignment, so by that definition it's a ... Of course the standard doesn't define the term, ...
    (comp.lang.c)
  • XML-tagging text document from W3C-schema
    ... Is there an XML-editor that can assist you in marking up the data in an urformatted text document, such that you mark the data and then right-click to access the Schema you have assigned, and choose the tag/attribute in the tree-structure, which then magically appears with your data enclosed? ... My assignment is to bring order to a truckload of stats from various Athletics events. ... For individual meetings, the formatting of the list of results are fairly standardized, but as a rule, they all follow their own standard, which means there's no hope making a script to automize the tagging, since there are several hundred meetings. ...
    (comp.text.xml)
  • Re: Concatenate integer to string
    ... in that the standard assignment operator will ... there was a work item to do allocatable character length in f2003. ... So if x is an array, ... The standard essentially requires that the ...
    (comp.lang.fortran)