x=r=y; // With r volatile. Is r read?

[Tim Rentsch]

On 3/8/2011 1:09 PM, Chad wrote:
[...]

The part I'm kind of fuzzy about is the ++b

in

int k = a++ + ++b;

The result of the preincrement operator to (applied) b is also a side
effect. However, I think this side effect is applied before the
statement completes. Ie, both b in incremented by one and the side
effect is applied to b. Whereas side effect of a++ is applied *after*
the statement completes.

No. Both the increments of a and of b are guaranteed to take place before
the statement completes. (Or, more technically, before the next "sequence
point".) When, exactly, during the execution of the statement, the
increments take place is not specified by the Standard.

However, the meaning of "a++" is "the value of a before the increment", and
"++b" is "the value of b after the increment". However, that does not
necessarily mean that "b" actually has been incremented by the time the
value of "++b" is used, nor that "a" won't be incremented before the value
is read.

In other words, this pseudo-code is a perfectly valid implementation of the
above code:

; extern int a,b;
; int k = a++ + ++b;

load k,a
add k,b
incr k
incr a
incr b

In fact, I believe this implementation is just as valid:

incr a
load k,a
add k,b
incr b

Despite the fact that we are using the value of "a++" after the increment,
and "++b" before the increment, the result is indistinguishable from the
other way around. (However, there may be a problem with this implementation
for values of a==INT_MAX and b<0 due to the overflow in "a++".

If a==INT_MAX then a++ produces undefined behavior so all
implementations are valid.

What you mean is that an implementation could exhibit any
particular behavior and still be a conforming implmentation.

If an implementation chooses to define the behavior on overflow as
doing a particular something (which the implementation is free to
do), and then does something else, it seems fair to say the
implementation is not conforming, at least in spirit if not in
letter. (I can't find any statement in the Standard that says the
required documentation for extensions and implementation-defined
behaviors must be accurate, but certainly it seems reasonable
that such accuracy is expected.)

 

[Phil Carmody]

On a related note, I'd like to point to an (IMHO) interesting paper.

Volatiles Are Miscompiled, and What to Do about It
http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf

And I'd like to point out that if it's the paper I'm thinking of,
it has some misunderstandings of what volatile actually means.
Trawl your favourite usenet archives for previous discussions
of this.

Phil

 

[Spiros Bousbouras]

[...]

If a==INT_MAX then a++ produces undefined behavior so all
implementations are valid.

What you mean is that an implementation could exhibit any
particular behavior and still be a conforming implmentation.

If an implementation chooses to define the behavior on overflow as
doing a particular something (which the implementation is free to
do), and then does something else, it seems fair to say the
implementation is not conforming, at least in spirit if not in
letter.

I wouldn't say that it's non conforming either in spirit or in letter ,
I would simply say that the documentation or the translator have a bug.

(I can't find any statement in the Standard that says the
required documentation for extensions and implementation-defined
behaviors must be accurate, but certainly it seems reasonable
that such accuracy is expected.)

It is expected for reasons of common sense and usability not because
the standard says so. I wouldn't expect the standard of any language to
say that the documentation of implementations should be accurate.

 

[Tim Rentsch]

On Tue, 08 Mar 2011 14:58:41 -0500

; extern int a,b;
; int k = a++ + ++b;

[...]

If a==INT_MAX then a++ produces undefined behavior so all
implementations are valid.

What you mean is that an implementation could exhibit any
particular behavior and still be a conforming implmentation.

If an implementation chooses to define the behavior on overflow as
doing a particular something (which the implementation is free to
do), and then does something else, it seems fair to say the
implementation is not conforming, at least in spirit if not in
letter.

I wouldn't say that it's non conforming either in spirit or in letter ,
I would simply say that the documentation or the translator have a bug.

(I can't find any statement in the Standard that says the
required documentation for extensions and implementation-defined
behaviors must be accurate, but certainly it seems reasonable
that such accuracy is expected.)

It is expected for reasons of common sense and usability not because
the standard says so. I wouldn't expect the standard of any language to
say that the documentation of implementations should be accurate.

You are entitled to your own opinions. My opinion is that the
Standard should state its requirements clearly and explicitly,
and not have to rely on any imaginative interpretations or
reading between the lines.

 

[Spiros Bousbouras]

On Tue, 08 Mar 2011 14:58:41 -0500

; extern int a,b;
; int k = a++ + ++b;
[...]

If a==INT_MAX then a++ produces undefined behavior so all
implementations are valid.

What you mean is that an implementation could exhibit any
particular behavior and still be a conforming implmentation.

If an implementation chooses to define the behavior on overflow as
doing a particular something (which the implementation is free to
do), and then does something else, it seems fair to say the
implementation is not conforming, at least in spirit if not in
letter.

I wouldn't say that it's non conforming either in spirit or in letter ,
I would simply say that the documentation or the translator have a bug.

(I can't find any statement in the Standard that says the
required documentation for extensions and implementation-defined
behaviors must be accurate, but certainly it seems reasonable
that such accuracy is expected.)

It is expected for reasons of common sense and usability not because
the standard says so. I wouldn't expect the standard of any language to
say that the documentation of implementations should be accurate.

You are entitled to your own opinions. My opinion is that the
Standard should state its requirements clearly and explicitly,
and not have to rely on any imaginative interpretations or
reading between the lines.

I agree. But I don't understand which imaginative interpretations or
reading between the lines you have in mind.

 

[James Kuyper]

On Thu, 17 Mar 2011 14:58:35 -0700


I agree. But I don't understand which imaginative interpretations or
reading between the lines you have in mind.

If the standard requires that something be documented, but a given
implementation's documentation documents it incorrectly, then the
correct thing is not documented. Therefore, the behavior that is
supposed to be documented, isn't, and the implementation therefore fails
to conform. Don't expect Tim to accept this argument; he can go on
forever arguing over such issues.

There's a flaw in this interpretation: what if an implementation
correctly documents everything it's supposed to document, and ALSO
documents one or more items incorrectly, and fails to provide any
mechanism for distinguishing the correct documentation from the
incorrect documentation. By my interpretation, that implementation has
met the standard's documentation requirements, which is rather problematic.

This is just a particular example of a more general problem: the
standard's documentation requirements are too weak to guarantee that the
documentation is useful. In particular, the standard does not specify
which language the documentation should be in; it doesn't require that
the documentation be available in any language that you know how to
read; it doesn't even require that it be written in a language than
anyone knows how to read. This is all left as a matter of Quality of
Implementation" (QoI). It is no more (or less) problematic than the fact
that the standard fails to impose any performance requirements on C
implementations: an implementation that takes one billion years to
execute the statement i++ could still be fully conforming (though
conformance testing could be very time consuming .

 

[Tim Rentsch]

If the standard requires that something be documented, but a given
implementation's documentation documents it incorrectly, then the
correct thing is not documented. Therefore, the behavior that is
supposed to be documented, isn't, and the implementation therefore
fails to conform. Don't expect Tim to accept this argument; he can go
on forever arguing over such issues.

Apparently Mr. Kuyper is bothered by being asked if he
can offer any facts in support of his opinions. Even
so it seems poor form to ignore my questions given in
direct response to his postings and then snipe at me
off in a response to someone else.