Re: Order of Variable
* Joshua Maurice, on 13.09.2010 20:56:
On Sep 11, 2:10 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
+use...@gmail.com> wrote:
* Johannes Schaub (litb), on 11.09.2010 22:54:
The way I understand it, it does not matter whether the reference is by an
union or not. Aliasing an int as a float is UB no matter by an union or not.
I thought that was the whole point of Gabriel's issue report? I.e if the
statements in foo are reordered, then "t.d" accesses an int object by a
double lvalue, violating aliasing.
Example to show what I mean:
union {
float f;
int i;
} u;
// now the object is a float, by 3.8/1.
u.f = 1.f;
// now it is an int, also by 3.8/1
u.i = 10;
// aliasing violation by 3.10/15 - UB, trying
// to access value of int object by float lvalue.
float f = u.f;
Yes. But if you consider
u.i = 42;
u.f = 2.71828;
float f = u.f;
Then you have valid code.
And then the compiler can't reorder the two assignment statements.
It can't reorder the assignment statements even if they're placed in a function
where it's not locally known that for a particular call the float and int are in
a union (Gabriel's point).
Indeed. This is a well known bug in the C and C++ specs. James talks
about it else-thread, quoted here:
You're calling a compiler bug a bug in the standard?
Well you make me laugh.
Also, note that we were discussing James' statements. It's completely
unnecessary to quote it again except to put it in a misleading new context.
[snip requoting of up-thread message]
And as I see it ?3.10/15 means that that's still the case when accessing A::x as
B::x where B is layout-compatible with A (assuming same member names for this
example).
Then you would be alone on your interpretation. I don't have a C spec
handy, but for C++03, that is not the case.
You can assert how much you want that other people agree with you, that none of
them agree with me, and that what the standard says is an "interpretation".
It's similar to your earlier assertion that a compiler bug is really a bug in
the standard.
It's a stupid argument.
This is what I can find on the subject in the standard itself.
C++03 standard, 9.2 Class members / 16
If a POD-union contains two or more POD-structs that share a common
initial sequence, and if the PODunion
object currently contains one of these POD-structs, it is permitted to
inspect the common initial part
of any of them. Two POD-structs share a common initial sequence if
corresponding members have layoutcompatible
types (and, for bit-fields, the same widths) for a sequence of one or
more initial members.
<<<<
The rule above only applies to PODs in a union.
C++03 standard, 9.2 Class members / 167
A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial
member (or if that member is a bit-field, then to the unit in which it
resides) and vice versa. [Note: There
might therefore be unnamed padding within a POD-struct object, but not
at its beginning, as necessary to
achieve appropriate alignment. ]
<<<<
The section above, especially with the (non-binding) note, pretty
clearly states that the C-style hack of inheritance may not work in C+
+.
No, it does not. It says nothing of the sort, or even related to that.
There might be unnamed padding which differs between different POD
structs.
Frankly though, this entire thing is a mess. When you compare the
guarantees of the two quotes, /which appear right next to each other
in the standard/, I don't understand how you can reconcile them in a
sane implementation. So, when the POD types are members of a union,
there's no difference in padding bits, but when the same POD types are
not members of a union, there might be extra magical padding bits.
What?
We expect that a compiler has a single rule for handling member
offsets so that accessing a member of an object is efficient, so it
doesn't matter if the POD object is a complete object or a member sub-
object of a union - the expected result is that the compiler will
generate the same assembly to access a member sub-object of the POD
object from a pointer to the POD object in all cases. With this in
mind, I have no clue how you're supposed to reconcile those two
sections above, one of which says there is no difference in padding
between lay-out compatible POD-struct types, and the next section
which says there might be a difference.
It's simple.
Whatever it is you are imagining is being said in the reinterpret_cast rule, is
not said there: it's only in your /imagination/.
However, at face value, most / all of the gcc examples in this thread
have been conforming.
Otherwise there would have to be some rule about exactly which pointer referent
types are considered to be sufficiently different that the pointers can be
assumed to be unaliased -- int != A?, A != B?, what?
Yes. That is exactly what "3.10 Lvalues and rvalues / 15" does. Hell,
there's a note on it which reads: "The intent of this list is to
specify those circumstances in which an object may or may not be
aliased."
We were discussing 3.10/15.
Cheers & hth.,
- ALf
--
blog at <url: http://alfps.wordpress.com>