Re: Order of Variable
On Sep 13, 12:24 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* 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 contex=
t.
[snip requoting of up-thread message]
And as I see it =A73.10/15 means that that's still the case when acces=
sing A::x as
B::x where B is layout-compatible with A (assuming same member names f=
or 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 n=
one 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 bu=
g in
the standard.
It's a stupid argument.
Could you please define compiler bug? I would loosely define it as a
compiler which does not follow its standard.
However, what if the standard is logically inconsistent? If the
standard is logically inconsistent, then I would not call any compiler
conforming nor non-conforming. One cannot abide by inconsistent rules,
and that is exactly the state of affairs with the C and C++ standards
with strict aliasing and unions. The rules are inconsistent, and
that's why I call it a bug in the standard.
Moreover, James has mentioned a possible preferred resolution of the C
committee, a resolution which makes the standard logically consistent,
and which also makes the gcc behavior talked about here conforming to
this new logically consistent standard.
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.
I know it's rather pedantic, but it specifically allows reading and
writing to the common leading part of layout-compatible POD-structs
but only when they're both members of the same union. By specifically
restricting it to only in a union, it is also saying that it does not
work outside of a union. With this in mind, you would need to find
another explicit rule which specifically allows casting from POD-
struct type T1 to layout-compatible POD-struct type T2 and reading and
writing to the common leading part. Can you find such a thing? I
cannot.
Otherwise there would have to be some rule about exactly which pointer=
referent
types are considered to be sufficiently different that the pointers ca=
n 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.
Then I am confused how you could make such a statement - you said "But
then there would have to be rules clarifying exactly how different the
pointer types would have to be to not alias", and exactly that is
specified in 3.10/15, which is why I brought it up (again).