Re: type based aliasing again - meaning of "undefined"

[craig at jcb-sc dot com]

>Sounds right (but why would anyone write a compiler that does that?). I
>think it's interesting that the example the standard gives for undefined
>behavior is integer overflow - imagine the uproar that would happen if you
>changed *that*. I guess it's just not obvious to me that the results of
>violating the type alias rules should be more like, say, dereferencing a
>null pointer (which I expect to cause problems) than like casting a
>pointer to an integer (which I usually expect to be consistent, if
>undocumented).

Immediately beyond the realm of what the standard defines lies the
land of "quality of implementation".  Beyond *that* land lies "buggy
user code".  Border disputes between those lands are common.  Border
disputes between defined and undefined lands occur, but the borders
themselves are usually pretty easy for people to spot.

It's mainly because the border between "undefined" and "defined" is
so much clearer than "reasonably-behaved according to the standard"
and "unreasonably-behaved such that it breaks code that most of us
think is pretty clear about what it wants to do, even though it is,
strictly speaking, undefined" that people who actually *work* on
compilers prefer the "undefined" border when it comes to making
long-term promises about how the compiler we maintain will or will
not behave.

The latter border just keeps moving all the time, so at no point
can a compiler developer *ever* even *think* (except in a state
of self-delusion) that he's going to perfect his product vis-a-vis
that border.  What to some people is "quality" is to other people
"broken", and vice versa.  Sometimes the very same people exhibit
two opinions within moments of each other.

Therefore, perfection in a compiler can be practically reached
only vis-a-vis defined vs. undefined behavior, plus reasonable
choices for implementation-defined behavior.  Anything beyond
that is an issue of "quality of implementation".  Of course,
on GCC, we rarely bother waiting on perfection before making forays
into quality-land, but, here, we're basically being asked to
maintain a military presence in broken-code land so the locals
will be able to pretend they're in quality land, on the basis that,
in the past, we hadn't actually dropped any missiles on that particular
corner of broken-code land.  That that corner of broken-code land thus
became infested with particularly large rats should *not* be our problem,
and we seem to be solving it already with this first missile, aka GCC 2.95
and its higher levels of optimization.

And it goes without saying that maintaining a military presence *two*
continents away, when one has not yet established supremacy in
the one in between, and one still has some flare-ups (aka bugs vis-a-vis
ISO C on at least some platforms) in ones' own land, is a *very* foolish
thing to try to do.  Promising one can do it amounts to knowingly
telling a lie, IMO.

        tq vm, (burley)