Re: inetutils

[Tim Rühsen]

On 2/23/20 10:16 PM, Alfred M. Szmidt wrote:
>    >    Also, the code seems to very buggy - my findings were triggered just 
> by
>    >    warnings from 'gcc -Wall -Wextra'. I didn't even take a closer look 
> into
>    >    the sources. Not even talking about test code coverage and fuzzing.
>    >
>    > Some of the code was ported from BSD 4.4-lite or something, and then
>    > has been tweaked and tuned.  Some tools are written from scratch, and
>    > they tend to be less buggy.  
> 
>    Observe that already Gnulib is responsible for too many warnings.
>    Running clang-3.4 on FreeBSD with '-Wall -Werror' aborts in 'lib/',
>    as does gcc-4.3.3 on OpenIndiana with '-Wall -Wextra -Werror',
>    whereas dropping '-Wextra' lets gcc-4.3.3 enter into proper Inetutils'
>    source before aborting.
> 
>    I remember complaining about this with bug-gnulib, at the time I was
>    beginning to engage for Inetutils, but got answers that it be of no
>    priority whatsoever. Therefor I stopped bothering about it.
> 
> Can we disable warnings from gnulib related code easily?

Define "easily". :-)

IMO, the way to go, if you use gnulib's bootstrap + bootstrap.conf:
- add 'warnings' module to bootstrap.conf
- add appropriate code in configure.ac to use the 'warnings' module
(e.g. craft your own WARN_CFLAGS and GNULIB_WARN_CFLAGS).
- add lib/Makefile.am which makes use of GNULIB_WARN_CFLAGS
- set the gnulib makefile in bootstrap.conf (e.g.
gnulib_tool_option_extras="--makefile-name=gnulib.mk")
- use WARN_CFLAGS in your other Makefile.am files

#### example lib/Makefile.am form GNU Wget2 ####
MOSTLYCLEANFILES =
noinst_LTLIBRARIES =
EXTRA_DIST =
BUILT_SOURCES =
MOSTLYCLEANDIRS =
CLEANFILES =
SUFFIXES =
LIBS =

AM_CFLAGS = $(GNULIB_WARN_CFLAGS) $(WERROR_CFLAGS)

include gnulib.mk
####

Example configure.ac, see L123ff at
https://git.savannah.gnu.org/cgit/wget/wget2.git/tree/configure.ac


As soon as I am in the FSF copyright database (signed Assignment has
been sent back a few days ago), I am willing to this, if you want me to do.

Also a configure option to enable ASAN / UBSAN is handy - the GNU Wget /
Wget2 projects have code for gcc and clang support.

Continuous Integration (CI) might also be an issue.

Another step would be to write fuzzers with integration as regression
tests and with integration to a continuous fuzzing platform like OSS-Fuzz.

What about test code coverage ? The CI can automatically generate lcov
reports and put them online. That is handy for extending the tests.

You sometimes read or hear "this is 20 years old proven code - don't
touch it" in the means of "the code never revealed any bugs, so there
are none". This is very wrong in many ways. Today's automated tools find
many more (partly security relevant) issues than hundreds or thousands
of developer's eyes before. This is especially true for C/C++ code.

Regards, Tim

signature.asc
Description: OpenPGP digital signature