Howard Chu writes:
> I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
> returning values through a void ** argument. As far as I can tell, this
> doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
> will complain. For example, take these two separate source files:
>
> alias1.c
> ####
>
> #include <stdio.h>
>
> extern void getit( void **arg );
>
> main() {
> int *foo;
>
> getit( (void **)&foo);
> printf("foo: %x\n", *foo);
This is not legal C. You are dereferencing a pointer to a type other
than the object that it points to.
This would have been quite legal, albeit implementation defined:
void **foo;
getit(foo);
printf("foo: %x\n", (int)*foo);
> }
> ####
>
>
> alias2.c
> ####
> static short x[] = {16,16};
>
> void getit( void **arg ) {
> *arg = x;
This is fine.
> }
> ####
>
> gcc -O3 -fstrict-aliasing -Wstrict-aliasing *.c -o alias
>
> The program prints the expected result with both strict-aliasing and
> no-strict-aliasing on my x86_64 box. As such, when/why would I need to
> worry about this warning?
Always. This isn't C code, and the compiler may not generate the code
you expect for it.
This has been explained countless times before. It certainly isn't a
suitable topic for the gcc mailing list, which is for development of
gcc, not help using it. Redirected to gcc-help.
Please read Section 6.3.2.3 of ISO9899:1999, in particular Para. 7.
Andrew.
