Re: netbsd-11 gcc bug

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Which is fair - but compilers do not have to take advantage of all
>> the leeway the standard gives them.  "Undefined behaviour" can,
>> after all, include "exactly what the code author intended".

> No, formally it can't, because "undefined" means "meaningless".

No, it means the compiler can do anything whatever.  As C99 puts it,

       3.4.3
       [#1] undefined behavior
       behavior,  upon  use  of  a nonportable or erroneous program
       construct or of erroneous data, for which this International
       Standard imposes no requirements

This can include generating code based on interpreting the construct in
question in any way whatever, including the one the code author
intended.

The construct may in some sense be formally meaningless, in that there
is no meaning formally defined for it, but that does not mean the
compiler can't choose to give it meaning.

As a simple example involving gcc, nested functions are formally UB (at
least as of C99), but gcc chooses to give them meaning.

> The root of these problems is that long ago a bunch of the undefined
> and unspecified behavior in C was understood as being that way to
> leave room for exotic hardware, and there was a corresponding
> expectation that the compiler would do the obvious thing and the
> exotic or not-so-exotic behavior of your actual hardware would
> determine the behavior.

Yes.  It was intended to be _useful_.

That is, after all, what compilers are for: to be useful.

> This understanding had already disappeared entirely upstream more
> than twenty years ago now,

Not entirely.  You can cast between pointers and integers and get
something useful - though that's IB rather than UB, so the compiler is
_somewhat_ constrained, but it would be formally fine (and likely
faster) for all casts from integers to pointers to produce nil
pointers.  Why is that not done?  Fundamentally, because it would make
the compiler less useful.  But somehow this, which also makes the
compiler less useful, is considered acceptable.  I don't get it.

> A third is that few people in the programming languages and compilers
> world, especially the academic parts of it, have any appreciation for
> (or real understanding of) C and think of it as a design bug with no
> redeeming features.

Such people have no business implementing C compilers, any more than I
have any business implementing an OCAML compiler.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B