On 15.12.2009 18:02, michal wrote: > Roland Scheidegger pisze: >> On 15.12.2009 14:14, michal wrote: >> >>> Guys, >>> >>> Does the attached patch make sense to you? >>> >>> I replaced the incomplete switch-cases with calls to u_format_access >>> functions that are complete but are going to be a bit more expensive to >>> call. Since they are used not very often in mesa state tracker, I >>> thought it's a good compromise. >>> >> They are not only used in state trackers, but drivers for instance as >> well. That said, it's probably not really a performance critical path. >> Though I'm not sure it makes sense to keep these functions even around >> if they'll just do a single function call. Also, I'm pretty sure your >> usage of the union isn't strict aliasing compliant (as far as I can tell >> you could just go back and remove that ugly union again), though it's >> probably one of the cases gcc won't complain (and hopefully won't >> miscompile). >> >> > I am casting to (void *) and then u_format casts it back to whatever it > needs to. I think I am innocent. Casts to void * and back to something are only safe if the "something" is the same as it initially was. Well in theory anyway. That's also where some of the initial warnings came from, callers using some pointer to unsigned, which then in the end got cast to ubyte * or whatever. An intermediate cast to void * doesn't change anything. That said, the callers probably couldn't have handled the formats not returning the right type anyway. Often though gcc won't complain about aliasing if you use some void * pointer in a function call and cast it to something else than it was, I think it usually won't be able to figure out what the original type was, hence it needs to assume it can alias with anything.
> > Anyway, I will go after Keith's suggestion and fill in only the > switch-default case. We can always nuke the special cases later when/if > we realise the performance impact can be neglected. Yes, sounds good. Roland ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
