On Sun, May 05 2019, Alessandro DE LAURENZIS <jus...@atlantide.t28.net> wrote:
> Hello Jeremie,
>
> On 05/05/2019 15:10, Jeremie Courreges-Anglas wrote:
>> On Sun, May 05 2019, Alessandro DE LAURENZIS <jus...@atlantide.t28.net>
>> wrote:
> [...]
>> Maybe there are lots of those warnings and fixing them all means
>> patching, but this is technically the wrong approach. The right
>> approach is to include the appropriate headers.
>>
>>> The problem is that in some files the "//" comment style has been used
>>> (and it isn't allowed in ANSI C - don't know why clang isn't
>>> complaining).
>>>
>>> We can simply use a more specific flag
>>> (-Wno-implicit-function-declaration" to obtain the same effect.
>>
>> Implicit function declarations was a misfeature of the C language, fixed
>> by C99. I don't think we want to go backwards.
>>
>
> Of course, I fully agree with you in principle; but pragmatically, since
> those headers doesn't exist,
I think most of those headers do exist, but not all functions are
properly declared. This code base seems to predate ANSI C and relies on
"implicit defaults to int".
> we have only 2 options here: either we
> accept the log "pollution" or we selectively hide those warnings
I'd rather have log "pollution" than hide potential problems. That said
given the age of the code base it makes sense to play by the rules of
ANSI C.
> (mind:
> I'm not saying that they aren't important, I just would like to
> empathize other messages that could be significant and that could be
> missed otherwise...)
>
> I'm already working with upstream in order to clean-up the code, but
> there are some more serious issues to solve with higher priority (not
> related to this port, which is just one of the tools
> developed/maintained by them, see [1]).
One serious issue, straight from the 80's, is the lack of feature
detection for lots of stuff, leading to ugly #ifdefs. For example,
using gcc -std=gnu89, the only warning you get is:
timing.c:103: warning: passing argument 1 of 'time' from incompatible pointer
type
The code passes a "long" instead of a "time_t" to time(3). If you look
at timing.c you see that time(3) is used as a fallback when neither
clock(3), times(2) or getrusage(2) are available. But to unveil the
better code, you need to add the appropriate -DHAVE_CLOCK to CPPFLAGS;
see base/config.h for more fun. It's a shame for a project using
autoconf-2.69.
>>> I don't have a sparc64 station, so I'm asking for confirmation.
>>
>> You can test on eg amd64 using
>>
>> make clean all CC=gcc CXX=g++
>
> Thanks; so using "-std=c89" I can replicate the issue reported; it is
> also confirmed that the errors go away using
> "-Wno-implicit-function-declaration.
gcc errors out because for ANSI C, C++ comments are an extension
disabled by -std=c89. To enable extensions, one should use -std=gnu89.
This fixes the build with gcc. ok?
Index: Makefile
===================================================================
RCS file: /cvs/ports/cad/netgen/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile 28 Apr 2019 20:51:27 -0000 1.2
+++ Makefile 6 May 2019 14:31:24 -0000
@@ -31,7 +31,7 @@ PATCHORIG = .patch.orig
WRKCONF = ${WRKSRC}/scripts
CONFIGURE_STYLE = gnu
CONFIGURE_ENV = CPPFLAGS="-I${X11BASE}/include" \
- CFLAGS="-std=c89 ${CFLAGS}"
+ CFLAGS="-std=gnu89 ${CFLAGS}"
CONFIGURE_ARGS = --with-tcl=${MODTCL_LIBDIR} \
--with-tk=${MODTK_LIBDIR}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
