Re: module level flags

[Alexandre Oliva <aoliva at redhat dot com>]

On Oct  1, 2002, Bruce Korb <bkorb@pacbell.net> wrote:

> You have that problem with "void*" aliasing or any other kind of
> aliasing.

Nope.  There are only aliasing issues when you actually dereference
the pointer, and you can't dereference a void*.  What the ISO C
Standard actually says is pretty much that dereferencing a pointer
invokes undefined behavior unless it actually points to an object of
that type or the pointer is a char*.  That's why, when you play
pointer tricks, you have to be very careful to make sure the compiler
won't use the `undefined behavior' laxity against you.

FWIW, the fact that it works for unions is a GCC extension.  It is not
guaranteed to work by the ISO C Standard, since, by the Standard,
using a member of the union that was not the one that you initialized
also invokes undefined behavior (unless you're accessing a common
prefix of two different structs, yadda, yadda).

>> All of a sudden, the code stops working because within that separate
>> function it is not known that *b may alias an object of type stumble?

> So, to protect users from this catastrophe, you silently destroy
> the efficacy of a pointer causing their programs to head south
> without a discernible error or even a warning.

The program in question is wrong, and such errors can't be detected in
general.  Of course detecting it in the few situations in which it is
possible would be a useful contribution to GCC, but the cases in which
it's really not obvious where the error is, the compiler is very
unlikely to be able to figure it out either, because it would require
information from multiple translation units.

> That's not a sufficient excuse for throwing up your
> hands on being helpful and silently generate trash.

Garbage in, garbage out.

The program invokes undefined behavior.  Go figure!

> Here's what it comes down to:  where feasible (99% of cases),

Yeah, there are 3 kinds of lies: lies, damned lies and statistics :-)
I guess what you're quoting with this figure, and whether this matches
Jakub's experience of getting RHL 7.0 to build with GCC 2.96RH, AFAIK
the first GNU/Linux distro to ship with a compiler that had
-fstrict-aliasing enabled by default.

> either emit working code (as I suggest), or emit a hard error.

A hard error would probably be inappropriate, since the compiler can't
tell in general whether the code in question would actually be
executed, a condition necessary for the undefined behavior to actually
be invoked.  But a warning would definitely be welcome, at least for
the easy cases.  I'd stand against emitting code as you suggest, since
this would have the sole effect of perpetuating such misconceptions
about what you can or cannot do in C.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer