On 08.12.2009 17:37, Keith Whitwell wrote:
> On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
>> Keith,
>>
>> I think there might be some slight issue with some of the changes in the
>> drivers I did. In particular, I was under the impression it would be ok
>> to do something like
>> union a_union {
>>   int i;
>>   double d;
>> };
>> int f() {
>>    double d = 3.0;
>>    return ((union a_union *) &d)->i;
>> };
>> but in fact gcc manpage tells me it's not (the example is from gcc 4.4
>> manpage) - this site told me this is ok, "casting through a union (2)"
>> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html,
>> I guess it was considered ok in 2006 but not now (though I'm not sure
>> why not)... I did that in some places because otherwise there's no way
>> around assigning the value to the union and pass that around instead.
>> Curiously though, despite the gcc manpage saying the code "might" not be
>> ok, gcc doesn't warn about it in the places I used it.
>> Anyway, I'm not sure it's worth bothering with this now, as drivers
>> could be fixed up without any interface changes.
> 
> Is it a lot of extra work to fix?  I wouldn't mind getting on top of
> this once and for all.

Not in the places I touched. It'll just make the code uglier, though at
least the compiler might still optimize extra assignments away.
For example in st_atom_pixeltransfer.c it now looks like this:
util_pack_color_ub(r, g, b, a, pt->format, (union util_color *)(dest + k));
and I'd need to change it to:
union util_color uc;
util_pack_color_ub(r, g, b, a, pt->format, &uc);
*(dest + k) = uc.ui;
Ok, not really a lot more ugly.
Will do this then, though there are other places where things like that
might already be used, and since the compiler does not issue any
warnings it might be a bit time consuming to find all of them.

Roland


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to