Re: module level flags

[Bruce Korb <bkorb at pacbell dot net>]

Zack Weinberg wrote:
> For reference, I believe the relevant section of C99 is section 6.5,
> paragraphs 6 and 7, and associated footnotes:
> 
>   6 ...
>   7 ...
> The code under discussion took the form
> 
> T foo (T arg)
> {
>   U *ptr = (U *) &arg;
>   *ptr = new_value();
>   return arg;
> }
> 
> where T and U are incompatible types.  The construct clearly does not
> satisfy any of the possibilities in 6.5p7, so undefined behavior
> results.
> 
> Bruce argues that since it is obvious what 'ptr' points to, that
> information should override the rules in 6.5p7.  The trouble with this
> argument is defining what qualifies as obvious.

I was meaning to argue that since a type 'T' was specifically cast
into a 'U', that within the context of 'foo', 'T' and 'U' should
be construed as aliasable.  "Seems obvious to me."  :-)

Failing that, 'T' is really compatible with any pointer type,
much like 'void*'.  The example is really:

> T foo (T arg)
> {
>   U**ptr = (U**) &arg;
>   while ((*ptr) -> next) != NULL)  ptr = (*ptr) -> next;
>   *ptr = new_value();
>   return arg;
> }

and that this is the intended usage for YYSTYPE (er, 'T').
So, if the first proposal is "too hard", then the backup
is to consider all scalars where ``sizeof(scalar)'' is
that of ``sizeof(void*)'' to be aliasable by any pointer.
This is *exactly* equivalent to the current aliasing 
treatment of ``void*'' and ``char*''.

What it really boils down to is this:  programming is hard.
Anything that makes understanding slippery or obtuse needs
to be reduced or eliminated to the greatest degree possible.
When you make an assignment like this:

>   U**ptr = (U**) &arg;

*especially* since it is encouraged by YACC, it is not obvious
that the compiler is going to take it upon itself to render the
pointer useless.  Worse, sometimes it will, sometimes it won't.
Worse still, it accepts it as completely valid and destroys
the result, leaving a program producing inscrutable results.

> I'd also like to point out that we have had this argument before.  See
> e.g. http://gcc.gnu.org/ml/gcc/1999-09/msg00316.html and the very long
> thread which followed, and please notice that the subject line is
> "type based aliasing *again*" (emphasis mine).

In that thread:
http://gcc.gnu.org/ml/gcc/1999-09/msg00323.html
Joe Buck wrote:
> So we have three variants.
> 
> A).  If we detect a rule violation, issue a warning and tell the compiler
>      to assume aliasing.
> 
> B).  If we detect a rule violation, issue a warning and tell the compiler
>      to assume no aliasing. (That is, produce bad code).
> 
> C).  If we detect a rule violation, issue an error and don't go on.
> 
> I think that only A) and C) are reasonable.
>   B) is not.  I would prefer A)

It seems we have chosen "B".  That's why I am squawking.

And John Vickers:(msg00381.html)
> On the warning side, in practice it seems that many offending constructs
> involve creating a single local variable, taking it's address, and
> casting that address to a different pointer type.  If even just that
> usage, within a single basic block, were diagnosed,  maybe a useful
> proportion of the problem cases would be caught.

Joe Buck:(msg00383.html)
> Exactly; post violations I've seen are of that type.  I can't aspire to
> the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
> missing this point: a whole lot of the errors we've seen are of this
> extremely simple form, with the entire error appearing in two or three
> adjacent lines of code.  We know the exact offsets of each address and
> can clearly see that they collide.

RMS & Jeff Law(msg00400.html)
>   > If the warning happens *often* for valid code, that could be a
>   > significant practical nuisance.  But the cases people are discussing
>   > are obscure, and should be rare enough that there will be no real
>   > nuisance.
> Agreed.  We'll have a much better idea how significant this issue is once
> we have some code to play with.

Now, you do.  Programs using YACC or tools with a similar interfaces
are suspect.  Just make pointer sized scalars aliasable by pointers.
"enhance" the ANSI spec.

RMS wrote:
http://gcc.gnu.org/ml/gcc/1999-09/msg00398.html
Yes!
http://gcc.gnu.org/ml/gcc/1999-09/msg00393.html
And yes again!

I'm tired now.  If GCC won't change and Bison produces non-aliasable
arguments, then I'll mess with autoconf/automake to have it suppress
alias analysis.  Trouble is, it would apply only to GCC 3.x and
following compilers.  What a waste.

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net