Re: x=(x=5,11)

On 22 Jun 2006 00:45:17 -0700, google@xxxxxxxxxxxxx wrote:

Barry Schwarz wrote:
On 21 Jun 2006 02:01:21 -0700, google@xxxxxxxxxxxxx wrote:


Barry Schwarz wrote:

<snip and summarize thus>

((*f(0))++, (*f(1))++) + ((*f(2))++, (*f(3))++)

<snip>

I agree that the standard is ambiguous about this (which is where we
came in on this discussion anyway) but I believe that the _intent_ of
the standard is that

(*f())++ + (*f())++ has undefined behaviour because a _valid_
optimization for a compiler that can see that f() always returns the
same pointer is:

But the standard is not ambiguous at all. There is a sequence point
before each function call and all side effects must be complete at
that point. Optimizations are required to behave "as if" all
requirements are satisfied.


g=f(); (*g)++ + (*g)++;

This was a red herring when it first entered the conversation and is
still a red herring.


i.e. the sequence points before and after the calls to f() only
constrain the side effects that occur in f() itself.

Where did you invent that from? There is no such thing as a partial
sequence point. Which ever call to f() is evaluated second is
guaranteed that all side effects of any previous evaluation are
complete.


So
S, f(), S, f(), S, inc, inc, S

is allowed.

This is subtly different from the subject line. In that case I think
the standard requires the assignment of 5 to x before the 11 is
evaluated (and so assigned to x) but I don't think the standard
_requires_ that the assignment of 11 to x starts _after_ the assignment
of 5 to x.

<snip>
Evaluations never cross sequence points. The whole purpose of
sequence points is to insure that the evaluation is complete.

Yes. But there is confusion when it comes to sub-expressions that
include sequence points. How much to they constrain things?

A sequence point is a sequence point. All side effects are complete.






What we are really interested in is whether the standard allows the
increment of f(1)++ to start before f(2) is called but to not complete
until the end of the full expression.

The standard guarantees that all side effects are complete prior to
the sequence point. Since there is a sequence point prior to the call
to f(2), the increment must be complete.

This is one valid interpretation. A second is that the sequence points
on the RHS have no effect on the LHS whatsoever and vice versa. A third
interpretation is that the sequence points on the RHS require that no
side effects are _still_ in progress on the LHS but do not otherwise
constrain when the side effects on the LHS can occur.

Only for some strange definition of the word all.


I would expect that it's actually the third interpretation that the
standard authors intended but it doesn't actually sound as reasonable
as either the first or second option when phrased as above.

Dream on.




consider g++ + f(); and (g=g+1) + f(); and (g=5) + f(); where f()
modifies g. Do these have defined or undefined behaviour?

It is still a red herring.


Since evaluating g in its many forms does not involve a sequence
point, this is nothing but a red herring.


huh? there's a sequence point both before and after the call to f() in
each of these therefore there is a sequence point between the
modifications of g.

Actually, the standard only talks about a sequence point at the return
from a *library* function. But you make my case for me.


I think these are interesting because one example I gave where the
subject line expression could give undefined results is where the
hardware only has the ability to flip bits so a write requires a read
first. For (g=g+1) + f(); clearly we can have:

read g
call f
add 1 to the g we read
write new g

Now if my hardware requires a read before write, does the standard
require a second read before the write in the above or is it legitimate
to reuse the first read? I think the standard should require that
second read. I'm not convinced it does.

There are lots of situations where it becomes murky. I am only
addressing the case described at the top of this message with four
calls to f.


Remove del for email
.

Relevant Pages

  • Re: Sub-sub-expression evaluation order
    ... > anything in the standard that says that it must complete (ignoring side- ... The evaluation can be implemented in any way, ... There are indeed sequence points at the beginning of each function's ... requirements of the standard and the code produces undefined behavior. ...
    (comp.lang.c)
  • Re: Defined bahavior or otherwise?
    ... >in the standard? ... Since the result cannot vary due to permissible variations in evaluation ... order between sequence points, ...
    (comp.lang.c)
  • Re: "Variables" tutorial available (Windows, mingw/msvc)
    ... For the benefit of those on this newsgroup who haven't got the standard ... the order of evaluation of operands of individual ... previous and next sequence point a scalar object shall have its stored ... But the standard says that it _is_ undefined behaviour. ...
    (comp.lang.cpp)
  • Re: Varied results for ++ operator in VC++/Unix.
    ... > int main ... ++a" does not contain any sequence point. ... C++ standard, the behaviour is undefined, so both answers are equelly ... modified at most once by the evaluation of an expression". ...
    (microsoft.public.vc.language)
  • Re: string upper, string lower, string subthisforthat
    ... | This requirement appears in the public draft standard (which is what ... as 'transform' can be used to modify a sequence in place ... | (i.e. one of the input iterators can be the same as the output ...
    (alt.comp.lang.learn.c-cpp)