[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
um at mutluit dot com
gcc-bugzilla@gcc.gnu.org
Mon Jul 2 20:27:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #6 from U.Mutlu <um at mutluit dot com> ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:
Example for the libiberty subdir: once w/o -Werror and once with -Werror:
< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no
And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...
So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> | /* Ultrix mips cc rejects this. */
> | typedef int charset[2];
> | const charset cs;
> | /* SunOS 4.1.1 cc rejects this. */
> | char const *const *pcpcc;
> | char **ppc;
> | /* NEC SVR4.0.2 mips cc rejects this. */
> | struct point {int x, y;};
> | static struct point const zero = {0,0};
> | /* AIX XL C 1.02.0.0 rejects this.
> | It does not let you subtract one const X* pointer from another in
> | an arm of an if-expression whose if-part is not a constant
> | expression */
> | const char *g = "string";
> | pcpcc = &g + (g ? g-g : 0);
> | /* HPUX 7.0 cc rejects these. */
> | ++pcpcc;
> | ppc = (char**) pcpcc;
> | pcpcc = (char const *const *) ppc;
> | { /* SCO 3.2v4 cc rejects this. */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> |
> | *t++ = 0;
> | if (s) return 0;
> | }
> | { /* Someone thinks the Sun supposedly-ANSI compiler will reject this. */
> | int x[] = {25, 17};
> | const int *foo = &x[0];
> | ++foo;
> | }
> | { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> | }
> | { /* AIX XL C 1.02.0.0 rejects this saying
> | "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> | }
> | { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> | }
> | return !cs[0] && !zero.x;
> | #endif
> |
> | ;
> | return 0;
> | }
As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.
I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.
More information about the Gcc-bugs
mailing list