Re: Stanard compliant bit-casting
On Mar 12, 1:26 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
Also, I started re-reading
http://cellperformance.beyond3d.com/articles/2006/06/understanding-st...
just now. It appears as though it's not perfectly accurate either.
And how. Or rather, it seems to be discussing in detail what
g++ actually does, rather than anything based on the standard.
(Note that there's also a problem with terminology. There is a
statement "Pointers to aggregate or union types with different
tags do not alias", but the example doesn't have any tags, and
the pointers in it are, in fact, allowed to alias in C, because
in C, the struct's Foo and Bar are the same type.)
It ignores the allowance that you can cast between POD types
with common leading parts and access the common leading parts
as expected. The article's very point about structs Foo and
Bar is actually inaccurate, though I support the article on
its intent to say "No. It doesn't work naively. The compiler
allowed to do non-obvious and surprising things because of the
strict aliasing rule."
That is, of course, the crux of the matter. If you have a
function:
void f(int* pi, double* pd)
The compiler will assume that pi and pd don't refer to the same
element. The standard clearly intends to give this guarantee,
although there are a very few cases where it in fact doesn't.
And the guarantee is important for optimizing purposes. Beyond
that, the standard is far from clear: from a QoI point of view,
I would expect the compiler to recognize visible aliasing, and
take it into account; if nothing else, not doing so is being
intentionally perverse. From discussions in the C committee,
prior to the formalizing of C90, I conclude that the *intent* is
1) that a checking compiler is allowed to somehow "discriminate"
unions, and detect cases where the accessed entry is not the
last written (modulo the few cases where this is guaranteed to
work), and 2) that the intent is that type punning be done by
casting. This conclusion is, of course, based on my memory and
my interpretation of discussions which occured a long time ago.
But pratically speaking, support for pointer casts in C doesn't
make sense otherwise.
Practically speaking, from a QoI point of view: if the compiler
sees a reinterpret_cast (or a pointer cast in C), it should be
clear that the programmer is doing something tricky at a very
low level, and that there *is* aliasing. Not taking that into
account is simply perverse. From a practical point of view,
too, unless the compiler is generating extensive debugging code
and actually discriminating unions, in order to detect errors,
the compiler should also make unions work as expected (but the
earliest versions of Microsoft C didn't); even in a debugging
compiler, I would expect some sort of option or pragma to allow
this common and traditional, albeit illegal, use of unions.
--
James Kanze