Bug 7824 - Impossible includes
Impossible includes
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 1999-12-15 19:31 EST by Riley H Williams
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-12-23 16:11:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Original source + "gcc -E"'d versions thereof... (33.53 KB, application/octet-stream)
1999-12-23 15:39 EST, Riley H Williams
no flags Details

  None (edit)
Description Riley H Williams 1999-12-15 19:31:23 EST
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!
Comment 1 Jim Kingdon 1999-12-23 11:15:59 EST
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>
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
Comment 2 Riley H Williams 1999-12-23 15:33:59 EST
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`

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> 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> 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.
Comment 3 Riley H Williams 1999-12-23 15:39:59 EST
Created attachment 44 [details]
Original source + "gcc -E"'d versions thereof...
Comment 4 Riley H Williams 1999-12-23 15:40:59 EST
Never mind about the emails, I was able to attach the tarball here anyway.
Comment 5 Jim Kingdon 1999-12-23 16:11:59 EST
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

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__).
Comment 6 Riley H Williams 1999-12-23 16:42:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.