Hello all, I'm having trouble understanding the infamous "dereferencing type-punned pointer will break strict-aliasing rules" warnings from GCC. I've read both of the following articles: 1) http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html 2) http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html but am still no wiser as to why the code I'm having trouble with is producing these warnings. I think the code is legitimate and is not actually violating the strict aliasing rules, and have found a "fix" to make the warnings go away. Comparing the generated assembler with and without the "fix" shows the same code, and it looks OK to me. However, I'd like to be 100% sure about this, so I'm asking here. The following short examples demonstrate my problem: ----Exhibit A #include <stdio.h> #include <stdlib.h> typedef struct { int foo; int bar; } item_t; int return_item (void **item); int return_item (void **item) { void *mem; mem = malloc (1); if (mem) { *item = mem; return 0; } else return 1; } int main (int argc, char *argv[]) { item_t *item; if (return_item ((void **)&item) == 0) { printf ("%p\n", item); free (item); } return 0; } ----Exhibit B #include <stdio.h> #include <stdlib.h> typedef struct { int foo; int bar; } item_t; int return_item (void **item); int return_item (void **item) { void *mem; mem = malloc (1); if (mem) { *item = mem; return 0; } else return 1; } int main (int argc, char *argv[]) { item_t *item; void *item_temp; if (return_item (&item_temp) == 0) { item = item_temp; printf ("%p\n", item); free (item); } return 0; } ---- The code is a generic example of the problem. The real code that is producing the problem is a hashing API which hashes (void *) and hence uses (void **) as an out parameter type. Exhibit A produces a warning as follows: [nodbug:mato]$ gcc -O2 -Wall -o aliasing-test aliasing-test.c aliasing-test.c: In function `main': aliasing-test.c:28: warning: dereferencing type-punned pointer will break strict-aliasing rules I'm using gcc version 3.3.5 (Debian 1:3.3.5-13) but the problem persists even when tested with GCC 4.x on newer systems. Exhibit B is my proposed "fix". Can anyone advise if the code in Exhibit A is legitimate, i.e. whether or not it's really violating the strict aliasing rules as defined by the C standard? If not, then I guess the warning is spurious and I can safely use the fix. If the code is in fact violating the standard then feel free to enlighten me how to fix it, since it seems like a legitimate thing to do :-) Thanks very much for any help, -mato