This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
gcc -O -Wconversion with glibc2 - warnings from headers.
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: gcc -O -Wconversion with glibc2 - warnings from headers.
- From: Oleg Goldshmidt <oleg at bfr dot co dot il>
- Date: 29 May 2000 18:28:50 +0300
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Hi everybody,
I just subscribed to start with a question. I searched the list
archive, the glibc GNATS database, the documentation that comes with
the source code, the glibc-HOWTO. Before sending a bug report I think
I have to ask here.
Platform.
Red Hat Linux 6.2 with kernel 2.2.14-5.0 on i686
Here is the full list of glibc RPMs that came with the distribution:
glibc-2.1.3-15
compat-glibc-5.2-2.0.7.2
glibc-devel-2.1.3-15
glibc-profile-2.1.3-15
GCC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Here is
the full list of egcs RPMs, just in case:
compat-egcs-5.2-1.0.3a.1
compat-egcs-c++-5.2-1.0.3a.1
compat-egcs-g77-5.2-1.0.3a.1
compat-egcs-objc-5.2-1.0.3a.1
egcs-1.1.2-30
egcs-c++-1.1.2-30
egcs-g77-1.1.2-30
egcs-objc-1.1.2-30
Here is the situation. We have a requirement that our C code should
compile with the strictest possible set of gcc warnings. In
particular, we use -Wuninitialized (that only works with optimization,
so we use -O2, this is important), and -Wconversion. The description
of both can be found in the gcc documentation, I can elaborate on
demand, but will skip it for now as irrelevant. Suffice it to say that
both warning options are very useful.
We get superfluous warnings using -Wconversion with optimization from
a couple of include files that come with glibc-devel-2.1.3-15.
Exhibit A:
/* foo.c */
#include <math.h>
int main(void) { return 0; }
$ gcc -c -O2 -Wconversion foo.c
/usr/include/bits/mathinline.h: In function `fabsf':
In file included from /usr/include/math.h:348,
from foo.c:1:
/usr/include/bits/mathinline.h:431: warning: passing arg 1 of `__builtin_fabsf' as `float' rather than `double' due to prototype
This is not a big problem, because it goes away when -ansi option to
gcc is used. We do not mind using -ansi, though we have no independent
reason to (we do use -pedantic - that does not help here).
Exhibit B:
/* foo.c */
#include <string.h>
int main(void) { return 0; }
$ gcc -c -O2 -Wconversion -ansi foo.c
/usr/include/bits/string2.h: In function `__strsep_g':
In file included from /usr/include/string.h:346,
from foo.c:1:
/usr/include/bits/string2.h:1171: warning: passing arg 2 of `__strpbrk_c2' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 3 of `__strpbrk_c2' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 2 of `__strpbrk_c3' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 3 of `__strpbrk_c3' with different width due to prototype
/usr/include/bits/string2.h:1171: warning: passing arg 4 of `__strpbrk_c3' with different width due to prototype
/usr/include/bits/string2.h contains some generic
(machine-independent) string-related optimizations that can be
switched off by using -D__NO_STRING_INLINES. Indeed, using
-D__NO_STRING_INLINES makes the problem go away. Not using
-O helps, too, but we lose -Wuninitialized then.
However, this is not entirely satisfactory. First, as far as I can
tell from looking at the header and running the preprocessor on it,
chars are passed to __strpbrk_c{2,3} where chars are expected. Can
anyone enlighten me?
Second, I am running gcc with a lot of warnings to verify that my code
does not do anything untoward. What I get is a lot of warnings from
the glibc headers that are at the very least annoying and distracting,
given that my own code is quite clean. If I do it on a lot of files
that include <string.h> I risk losing real warnings among all the
bogus ones. And why should there be bogus warnings (assuming they are
bogus) from glibc?
Third, the -D__NO_STRING_INLINES is really ugly. It should not be
mandatory for clean compilation of "return 0", should it?
So, questions:
1) Is it a bug in glibc? Not necessarily, actually, since -Wconversion
tells you, among other things, what would happen were you not using
prototypes (read: ANSI C), besides pointing out real
problems. However, I don't expect such warnings from the C library,
so it may still be a bug in this context.
2) If it is not a bug, is there a clean solution to the problem that I
have: compiling perfectly clean code with a certain warning flag to
gcc yields a lot of totally superfluous warnings? By "solution" I
mean something cleaner than the non-obvious -D__NO_STRING_INLINES,
that can only be called a kludge or a hack.
Thanks a lot in advance,
--
Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | oleg@NOSPAM.bfr.co.il
"... We work by wit, and not by witchcraft;
And wit depends on dilatory time." - W. Shakespeare.