Opened 11 years ago
Closed 8 years ago
#1107 closed defect (fixed)
Compiling with OpenBSD's gcc-4.2.1 produces 2 warnings when compiling posixunix.c
Reported by: | Christian Kellermann | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.12.0 |
Component: | core libraries | Version: | 4.8.x |
Keywords: | Cc: | ||
Estimated difficulty: | medium |
Description (last modified by )
The line numers differ from building the latest dev snapshot and master but the source code line is the same:
posixunix.c:9214: warning: array size (4) smaller than bound length (1024)
The line in question contains:
t3=C_curdir(t2);
The second warning is generated for the line:
t2= C_do_readlink(t1,((C_word*)t0)[2]);
Compiling with a newer gcc (4.8.2) from ports does not show these, so this might be a compiler optimisation bug in gcc or a bogus warning.
Compiling with -O0 still produced the warnings.
This has been observed on a 32-bit i386 Openbsd 5.5-current machine.
Change History (11)
comment:1 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 11 years ago by
I just tested adding --std=c99 to Makefile.bsd, but that breaks the build due to missing alloca
comment:3 Changed 11 years ago by
I get rid of the warning with --std=gnu99 which is c99 with GNU extensions, does that work on NetBSD?
comment:4 Changed 11 years ago by
Milestone: | 4.9.0 → 4.10.0 |
---|---|
Priority: | critical → minor |
I am fine with postponing the fix for this as changing the compiler flags is risking breakage on almost every other platform (and potentially eggs), so we will stick with this warning for 4.9.0. Eventually the code path taken for clang should be unconditionally be used.
comment:5 Changed 9 years ago by
Milestone: | 4.10.0 → 4.11.0 |
---|
comment:6 Changed 9 years ago by
Milestone: | 4.11.0 → 4.12.0 |
---|
Moving to 4.12.0, as the fix (adding --std=gnu99) has the potential to break eggs and other user code.
comment:7 Changed 8 years ago by
Estimated difficulty: | → medium |
---|
comment:8 follow-up: 9 Changed 8 years ago by
The GCC manual says:
gnu90 gnu89 GNU dialect of ISO C90 (including some C99 features). This is the default for C code.
...
gnu11 gnu1x GNU dialect of ISO C11. This is intended to become the default in a future release of GCC. The name gnu1x is deprecated.
According to the GCC changelog, GCC 5 already has this option by default. That probably means this problem will go away as soon as OpenBSD updates to GCC 5 (or as soon as they start using clang exclusively).
So instead of hardcoding what sounds like a GCC-specific option (-std=gnuxx), maybe a better approach is to just ignore this warning (because to me this warning sounds bogus, and fixing it is just yak shaving).
C-Keen: Can you verify that the problem is gone if you use GCC 5 from ports?
comment:9 Changed 8 years ago by
Replying to sjamaan:
According to the GCC changelog, GCC 5 already has this option by default. That probably means this problem will go away as soon as OpenBSD updates to GCC 5 (or as soon as they start using clang exclusively).
So instead of hardcoding what sounds like a GCC-specific option (-std=gnuxx), maybe a better approach is to just ignore this warning (because to me this warning sounds bogus, and fixing it is just yak shaving).
C-Keen: Can you verify that the problem is gone if you use GCC 5 from ports?
Unfortunately no. The -current ports tree includes a GCC 6.2 port now, no 5.x and that port is currently broken due to an unresolvable GNU M4 version dependency I cannot resolve.
But for the means of this ticket, closing it with won't fix would do for me, if you also agree.
comment:10 Changed 8 years ago by
Looks like that changelog is a bunch of lies. The version of Cygwin I have on Win7 ships GCC 5, but it passing no --std option at all doesn't have the same effect as passing --std=gnu99.
I now think passing --std=gnu99 is the sanest approach to this mess.
comment:11 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should be fixed now, by 2a32b6f / 02dcbe1.
This seems to be due to #778. For some reason gcc doesn't define the standard that's being used (perhaps we should add --std=c99 just in case? But then it would break on platforms that have an older gcc)