[cpp-threads] RE: volatile, memory models, threads

[Nick Maclaren]

"Peter Dimov" <pdimov at mmltd.net> wrote:
>
> > Well, you may be right, but there is nothing that you have quoted that
> > states (or even implies) that 3.9.3/1 refers to the object
> > representation rather than the value representation.  My assertion is
> > that it can be read either way, and the footnote strongly implies the
> > latter.
> 
> Referring to the value representation would be meaningless in this context. 

Not merely is it not meaningless, it is what a great many compilers
actually have done and probably still do.  You seem to be ignoring that
simple fact.

> The value representation of a const int x is completely invisible to a 
> conforming program, because in order to inspect, for example, value bit 0, 
> you need to write x & 1, and the lvalue to rvalue conversion drops the 
> qualifiers, so you're actually looking at the value representation of the 
> corresponding non-const int.

Ah.  You're getting warmer.

The point is precisely what you are saying, but more so.  The reason that
the wording is critical for value representation is that there were and
are systems like the VAX and x86/etc. which have multiple, inequivalent
value representations.  Without that wording, it would be perfectly
possible for an implementation to use one form for volatile double and
another for ordinary double.  There are good reasons for wanting to so
that, incidentally, but they are very confusing to naive users, which is
why C needed to forbid it.

Now, for the reasons you say, it isn't possible to inspect the object
representation of a result until it is stored or that of an argument
until its lvalue is taken - and that is the reason that the use of the
'&' operator on an argument anywhere in a function can impact the
calling efficiency even if the '&' operator is never executed.  BCPL
and K&R experts will be familiar with how one can pass data in registers
while still allowing that.

> This is all pretty basic knowledge, seriously. :-)

It's not what you don't know that causes the trouble; it's what you
know that ain't so.

> But why does it matter? The definition of an object is a sequence of N 
> bytes, where N is returned by sizeof. A POD object is completely determined 
> by these bytes, you can read them, encrypt them, decrypt them into another 
> sequence of N bytes (with the appropriate alignment), and you'll have a copy 
> of the original object back.

That is true, but you are not allowed to change type while doing so.
and cv-qualified types are not the same as the unqualified types
(3.9.3).

Look at 3.9/2, 3.9/3, 3.9/11, 3.9.2/3.  Why do these not say "(possibly
cv-qualified)", as it does elsewhere?  Why does the standard not say
that the cv-qualified and unqualified types are layout-compatible? 
Because it clearly says that they are not required to be.

I agree that 3.9/3 seems to copy between a const T object and a T one,
but that is illusory; the objects are both T and it is only one of
the pointers that is 'const T *'.  So we are back to the ability to
add cv-qualifiers again.

> 3.9.3/1 seems pretty clear to me, sorry. :-)

It seems pretty clear to me, too.  But incompatibly.

> It is actually pointer arithmetic that imposes the size requirement if we 
> pretend that 3.9.3/1 doesn't. A language that doesn't have pointer 
> arithmetic can have 'int const' with alignment 4 and 'int' with alignment 8, 
> and every int* would be a valid int const*, but not vice versa.

No, it isn't.  There is no problem about pointer arithmetic - it is
just relative to the sizeof value of the type, and cv-qualified and
unqualified types are different types.  The ONLY linkage is the ability
to add cv-qualifiers - nothing else.  Break that for a particular
qualifier, and the sizeof sizes can vary.

Look, this is getting ridiculous.  I have given you chapter and verse
from the standard.  If you can provide equivalent references, please do
so.  If not, please stop contradicting the standard with what I agree
are common assumptions.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679