Compiling with OpenBSD's gcc-4.2.1 produces 2 warnings when compiling posixunix.c

[Christian Kellermann]

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.

[sjamaan]

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)

[sjamaan]

I just tested adding --std=c99 to Makefile.bsd, but that breaks the build due to missing alloca

[Christian Kellermann]

I get rid of the warning with --std=gnu99 which is c99 with GNU extensions, does that work on NetBSD?

[Christian Kellermann]

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.

[sjamaan]

Moving to 4.12.0, as the fix (adding --std=gnu99) has the potential to break eggs and other user code.

[sjamaan]

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?

[Christian Kellermann]

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.

[sjamaan]

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.

[sjamaan]

This should be fixed now, by 2a32b6f / 02dcbe1.