When I compile SatTrack 3.1 (the satellite tracking system for Linux), I get the following warnings: /usr/include/bits/string2.h: In function `__strsep_g': /usr/include/bits/string2.h:1168: warning: passing arg 2 of `__strpbrk_c2' with different width due to prototype /usr/include/bits/string2.h:1168: warning: passing arg 2 of `__strpbrk_c3' with different width due to prototype /usr/include/bits/string2.h:1168: warning: passing arg 3 of `__strpbrk_c2' with different width due to prototype /usr/include/bits/string2.h:1168: warning: passing arg 3 of `__strpbrk_c3' with different width due to prototype /usr/include/bits/string2.h:1168: warning: passing arg 4 of `__strpbrk_c3' with different width due to prototype I've checked these out, and they appear to be due to an incorrect prototype in the string2.h include file as named. I've no idea where to report this problem, so have put it here and ask for help. Anybody please!
It would seem to be some kind of incompatibility between the compiler and glibc (perhaps triggered by certain compiler options). I tried reproducing the bug with a small test case (enclosed) and I tried -Wall, -O2, and -pedantic options and that didn't seem to do it. Can you send a self-contained test case? (usually the best way to do that is to take one of the source files which is giving the error and send the output of gcc -E on that source file). ------------------ begin sep.c #include <stdio.h> #include <stdlib.h> #include <string.h> int main (int argc, char **argv) { char *p; char *q; int i; if (argc != 2) { printf ("Usage: sep tok1,tok2,tok3,...tokn\n"); exit (EXIT_FAILURE); } p = argv[1]; i = 0; while ((q = strsep (&p, ",")) != NULL) printf ("Token %d is \"%s\"\n", i++, q); exit (EXIT_SUCCESS); } ------------------- end sep.c
I've now applied your advice and done "gcc -E ..." on one of the files reporting that error. However, the results are a little large to post here, so can I email them to you separately? One thing though: It looks like it's something to do with gcc's optimisation, as `gcc -Os` doesn't produce those warnings, although both `gcc -O` and `gcc -O2` do. For reference, here's the original compilation command for the section that I used -E on: Q> gcc -O -Wall -Wconversion -DIOCTL -c -DREVERSEVIDEO -DSUNTRANSITS \ Q> -DXWINDOW -I/usr/src/SatTrack-3.1.7/src/include \ Q> /usr/src/SatTrack-3.1.7/src/fixchecksum/fix checksum.c \ Q> -o /usr/src/SatTrack-3.1.7/obj/fixchecksum.o The following is the bash script I used to perform these tests: Q> #!/bin/bash Q> Q> function run() { Q> gcc -E $1 -Wall -Wconversion -DIOCTL -c -DREVERSEVIDEO \ Q> -DSUNTRANSITS -DXWINDOW -I/usr/src/SatTrack-3.1.7/src/include \ Q> /usr/src/SatTrack-3.1.7/src/fixchecksum/fixchecksum.c \ Q> \ Q> | tr -s '\t' ' ' | sed 's/^ $//' | uniq Q> } Q> Q> run -O | tee fixchecksum-O.c Q> run -O2 | tee fixchecksum-O2.c Q> run -Os | tee fixchecksum-Os.c I can report that the output of the first two tests was identical. Here's a directory listing of the resultant files: -rw-r--r-- 0/0 102694 Dec 23 19:44 1999 fixchecksum-O.c -rw-r--r-- 0/0 102694 Dec 23 19:44 1999 fixchecksum-O2.c -rw-r--r-- 0/0 47201 Dec 23 19:44 1999 fixchecksum-Os.c -rw-r--r-- 0/0 9358 Jan 4 21:21 1997 fixchecksum.c As you can see, the result of the -Os test is considerably smaller than the other two.
Created attachment 44 [details] Original source + "gcc -E"'d versions thereof...
Never mind about the emails, I was able to attach the tarball here anyway.
Well, it is caused by -Wconversion. The header contains the prototype: extern __inline char *__strpbrk_c2 (__const char *__s, char __accept1, char __accept2); and that kind of prototype (with type "char") is exactly what -Wconversion is supposed to be warning about, if you look at the documentation of -Wconversion. As for -O2, it isn't optimization as such, it is the fact that turning on optimization causes the compiler to define __OPTIMIZE__ which the glibc headers test for when deciding whether to use inlines and #define and so on. The solution? The only two that are springing to mind are (1) persuade the glibc people not to do that, or (2) don't use -Wconversion. I think I'd suggest the latter. I'm not thinking of anything that GCC should be doing differently (although I suppose a case could be made for __extension__).
That makes sense, but... If that's what the problem is, why doesn't it show with -Os as well? The only reason I used -Wconversion is because it was used in the original, and I can also confirm that the SAME files, when compiled under RedHat 4.2 as distributed, and with the SAME options, did NOT produce those warnings.