Re: DR#236 analysis

[Daniel Berlin <dberlin at dberlin dot org>]

On Fri, 2004-12-03 at 03:31 +0000, Joseph S. Myers wrote:
> An analysis of C99 DR#236 (type-based alias rules in the presence of 
> unions) with a possible resolution with a note "Optimizers may have 
> problems here" has been posted in the posted in the post-Redmond mailing 
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1090.htm>; I'd suggest 
> people trying to implement aliasing rules read it.  Any comments about 
> what resolutions make sense for optimizing real code would probably best 
> go to the WG14 reflector (sc22wg14 at open-std.org) though I don't know to 
> what extent non-member postings are accepted.
> 

They don't seem to be accepted (i tried).
So i'll just state my thoughts here, and if anyone wants to pass them
along, they can.

They just don't seem to want to do the right thing, which is just make
the all or nothing choice and deal with the results.

The whole idea that it is more sane to change the rules at function
boundaries seems broken, even if i like the fact that it provides more
certainty than what we have have now.  

I feel this way partially because lots of optimizations in real world
compilers cross function boundaries, and that raises a whole host of
issues with this.

The simplest example is inlining on the whole program (or single modules
if these were all in the same module, etc) could make every single piece
of example code given the same in terms of intermediate form.  So what
happens then? Are we supposed to track what the aliasing rules say the
result would have been, had it not been inlined, or apply the type based
aliasing rules to the newly created inline function to determine whether
it is now valid, even if it would originally have been invalid in the
non-inlined form?

Bright lines are better than squiggly half-lited ones, and carving out
weird exceptions only leads to carving out further weird exceptions when
you need to accomodate something sane later that happens to conflict[1].

Either decide that point a (in the intention of the aliasing model) is
more important, or point c is more important (and for an optimizing
compiler, point a is much more important), and be done with it.  Drawing
the line in the middle and cutting the baby in half helps no one. 

Part of the reason we have language committees is in part to make the
hard choices so that both programmers and compiler authors don't have to
deal with the uncertainty that results otherwise.

Lastly, I completely agree with whoever raised the point that there is
no good reason for any of this code to be valid in the first place.
Is it really that difficult to explicitly access a union field when you
want to access a union field?

--Dan
[1] This is no different than law, where most of the time in law school
classes is spent teaching you the exceptions and squiggly lines that
were carved out (most of time, with some exceptions) because of some
court originally punting on making a hard choice one way or the other,
and then it coming back to bite them in the ass later because they were
more or less stuck with it at that point.