This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gcc -O -Wconversion with glibc2 - warnings from headers.



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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]