Re: -Wstrict-aliasing in 2.95/6?

[patl at curl dot com (Patrick J. LoPresti)]

 patl> And in the commonly desired case of memcpy and friends, you
 patl> really want to be able to alias anything at all.

 Jamie> Not if it's inline.  Counterexample:

Point taken.

 Jamie> The read macro has to make sure the read isn't moved around
 Jamie> normal writes -- I think clobbering memory is the only way to
 Jamie> ensure this.

I know.  I was just pointing out how your solution is less optimal
than a type adjective, just as a type adjective is less optimal than a
union.

 Jamie> Ideally there'd be a way to declare a read barrier:
 Jamie> i.e. "memory" as an asm input operand rather than a clobber.
 Jamie> But there isn't.

Perhaps GCC should provide a platform-independent way to declare
finer-grained barriers.  It would certainly allow some interesting SMP
code to be written more portably (across architectures, not compilers,
of course).  But alas, we digress.

 Jamie> I don't see a strong case for adding a type attribute: the
 Jamie> macros aren't that hard to use instead of type casts, and they
 Jamie> make it very clear that there's a potential aliasing issue.
 Jamie> They say "TAKE CARE HERE".

I would say that

  (may_alias int *)foo = bar;

is pretty clear.

My argument is purely one of usability, which is totally subjective.
How much effort has been spent trying to learn what David Miller,
Linus, etc. would consider "not that hard to use"?

A type adjective is very easy to read compared to a macro, and it
would be a lot easier to munge into existing code (at least the code I
have seen as examples).  A typedef, some judicious search&replace on
certain integer casts, and you are done.

 Jamie> It would be nice to get more refined aliasing specs.

Agreed.

So is anyone else actually listening, or are you and I just having a
private conversation on the EGCS list?

 - Pat