In /usr/include/bits/string2.h there are a number of constructs like __u = __extension__ ((void *) __u + 2); When this code is compile with -Wpointer-arith the compile will complain about it: /usr/include/bits/string2.h:419: warning: pointer of type `void *' used in arithmetic /usr/include/bits/string2.h:427: warning: pointer of type `void *' used in arithmetic /usr/include/bits/string2.h:432: warning: pointer of type `void *' used in arithmetic /usr/include/bits/string2.h:437: warning: pointer of type `void *' used in arithmetic /usr/include/bits/string2.h:439: warning: pointer of type `void *' used in arithmetic /usr/include/bits/string2.h:444: warning: pointer of type `void *' used in arithmetic Because these things are marked with __extension__ the compiler should understand that that is the indended use and quit whining. This is very annoying and we need it fixed quite fast :-) It seems to be a bug in the current compile - it seems that gcc 2.95 does not ahve the problem, so maybe there is a possibility of backporting a patch...
For Ulrich's reaction see http://sourceware.cygnus.com/ml/libc-alpha/1999-08/msg00113.html Are you sure this changed in GCC 2.95? Looking at the source to 2.95 I don't see anything which has __extension__ interact with anything other than -pedantic (which is the way it is documented). Off the top of my head it strikes me as better to patch glibc (which recently changed on this point) rather than patching gcc (which has not changed the behavior of __extension__ in a long time), if we really do need something fast. Patching gcc in a way that the gcc maintainers won't end up liking would just make things worse.
I do not get those warnings with gcc 2.95, so something changed and made the compiler to correctly protect extensios against -Wpointer-arith. It *is* a bug in the compiler.
I just tried this with the latest gcc from cvs and I got the same warnings (test case enclosed in the email section). If you want to point me to a gcc 2.95 binary (or wait for me to download and build it), I can try that too but I really don't think the version of gcc has much to do with it. Were you using -O in your tests (that is required since string.h tests __OPTIMIZE__)? I mean, I'll send email to gcc-bugs and see if people have reactions (and I can certainly write a patch if that is what we want). But if this is a matter of just backporting code which is already there, I am missing something in a big way.
Patch at http://egcs.cygnus.com/ml/gcc-patches/1999-09/msg00266.html and in egcs-1.1.2-23.
Still working on getting this into GCC: http://egcs.cygnus.com/ml/gcc-patches/1999-09/msg00972.html
Checked into GCC mainline (ChangeLog entry dated 22 Sep 1999).