GNOME Bugzilla – Bug 122777
type-punned pointer warnings
Last modified: 2006-10-07 16:01:38 UTC
This patch gets rid of some warnings of the following type: gdkdnd-x11.c: In function `xdnd_read_actions': gdkdnd-x11.c:2353: warning: dereferencing type-punned pointer will break strict-aliasing rules gdkdnd-x11.c: In function `xdnd_enter_filter': gdkdnd-x11.c:2522: warning: dereferencing type-punned pointer will break strict-aliasing rules These are all over the place in gtk+ and the rest of GNOME CVS so this is just me sort of testing the waters wrt this kind of change.
Created attachment 20117 [details] [review] patch for warnings
A) These warnings are actually GCC bugs. GCC puts out all sorts of warnings it shouldn't on this issue, and really needs to be fixed. B) The fix here isn't (IMO) right ... it loses significant type safety. You can look at the workarounds I put into Pango for the issue ... it frequently involve introducing a temporary variable.
I commited similar stuff to gnome-panel with George's blessing, maybe this should be discussed outside of bugzilla to get attention to the problem? If it's a genuine gcc bug maybe we should add defailt compiler flags to quench the warning just to avoid drowning in the noise?
- Your fixes aren't actually *wrong*, but I don't like the fact that they fix the warnings by obscuring what is going on from the compiler. The Pango workarounds try to avoid that - by generally providing more information to the compiler than the original. - There are no flags that can be used to disable this warning. - Fixing gcc here is not necessarily simple, and almost certainly would require extensive debate with the GCC maintainers. Worth doing, but someone would have to have the time.
Wouldn't -W-no-strict-aliasing remove the output of these warnings?
Actually, from reading the C99 standard, and having a little discussion on gimp-developer, it looks like gcc doing the right thing here, and leaving it is could cause problems in the future, since a compiler might assume the value wont change during the function call, so it could cache it in a register. Would be good to fix these bugs in a typesafe manner, and perhaps fix the api of some of the functions in glib that rely on this.
Reference for the last comment?... the C standard only talks about *accessing* the memory through the pointer, I don't really think the compiler would know that the pointer couldn't be cast back and accessed as the original type.
C99 standard, see http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm 6.5: Expressions 7. An object shall have it's stored value accessed only by an lvalue expression that has one of the following types 61): -- a type compatible with the effective type of the object, -- a qualified version of a type compatible with the effective type of the object, -- a type that is the signed or unsigned type corresponding to the effective type of the object, -- a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, -- an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or -- a character type. 61) the intent of this list is to specify those circumstances in which an object may not be aliased.
See Bug 141080. It's an attempt to try to resolve these warnings, by using temporary variables. Not sure if it would be acceptable, but it's a start.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
Looks like these were fixed in revision 1.76 of gdkdnd-x11.c by Owen. Should we close this report?
Closing. The warnings were fixed.
*** Bug 141030 has been marked as a duplicate of this bug. ***