Opened 7 years ago

Closed 5 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 sjamaan)

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 7 years ago by sjamaan

Description: modified (diff)

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)

comment:2 Changed 7 years ago by sjamaan

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

comment:3 Changed 7 years ago by Christian Kellermann

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

comment:4 Changed 7 years ago by Christian Kellermann

Milestone: 4.9.04.10.0
Priority: criticalminor

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 6 years ago by sjamaan

Milestone: 4.10.04.11.0

comment:6 Changed 5 years ago by sjamaan

Milestone: 4.11.04.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 5 years ago by sjamaan

Estimated difficulty: medium

comment:8 Changed 5 years ago by 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?

comment:9 in reply to:  8 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by sjamaan

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.