bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Jim Meyering <jim@meyering.net>
Cc: bug-gnulib@gnu.org
Subject: warnings in unit tests
Date: Tue, 08 Jun 2021 04:40:52 +0200	[thread overview]
Message-ID: <2113844.jgEgOJX5uS@omega> (raw)
In-Reply-To: <CA+8g5KEMG0TvLzG5Ms1R35rx7XUGXRMTNms5MCNN32e6xYpX6Q@mail.gmail.com>

Hi Jim,

> > > > @@ -183,6 +183,9 @@ main ()
> > > >        *(volatile int *) (page + 0x678) = 42;
> > > >        break;
> > > >      case 3:
> > > > +#if 6 < __GNUC__
> > > > +# pragma GCC diagnostic ignored "-Wnull-dereference"
> > > > +#endif
> > > >        *(volatile int *) 0 = 42;
> > > >        break;
> > > >      case 4:
> > >
> > > We shouldn't spend time eliminating warnings from test code.
> > >
> > > The goal is to have a good coverage of the lib/* code with unit tests.
> > > That means, we need to
> > >   - make it easy to write unit tests,
> > >   - not make it time-consuming to maintain them.
> > >
> > > Eliminating warnings from lib/* code is useful, to avoid bugs in the
> > > programs. But eliminating warnings from tests/* code goes against the
> > > goal of increasing test coverage.
> 
> Hi Bruno,
> Isn't this code exceptional enough to merit three lines of warning suppression?

No. Good unit tests do exceptional things, like calling close(-1), passing
NULL pointers to various functions, and other things that e.g. Coverity
warns about.

> I would like to continue to use -Werror with most warning options even
> in test code,
> as long as the cost is low. This feels like a very low one-time cost.

No, the cost is not low. Dmitry's patch also changed the linkage of 11
functions. He did so to silence warnings (-Wmissing-prototypes) which are
  1) not part of '-Wall',
  2) just pointless for tests [my opinion as maintainer of most of these
     tests].

I don't want the maintainers of packages that use Gnulib to push costs
onto Gnulib, when it is just for their personal preference.

The tests in Gnulib are there to evaluate the reliability of Gnulib's
modules on a particular platform. The more test coverage we have, the
better.

Warnings in the unit tests are not problems. Test *failures* are problems.

gnulib-tool has options --with-tests and --tests-base, that allow a
package to ship the Gnulib tests and thus help Gnulib (by having more
people run the unit tests and report possible test failures).

If a package maintainer insists on having warning-free builds, I kindly
ask them to not bundle the Gnulib tests any more — because requiring
warning-free tests from Gnulib is more of an impediment than of a help.

For those package maintainers who are OK to accept warnings in the
Gnulib tests directory, on the other hand, I repeat my offer to
automatically add -Wno-error in the tests/Makefile.am of that directory.

Bruno



  reply	other threads:[~2021-06-08  2:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 17:01 new module 'sigsegv' Bruno Haible
2021-06-06 23:27 ` Dmitry V. Levin
2021-06-07  0:49   ` Bruno Haible
2021-06-07 10:29     ` Dmitry V. Levin
2021-06-08  1:45       ` Jim Meyering
2021-06-08  2:40         ` Bruno Haible [this message]
2021-06-08  5:55           ` warnings in unit tests Jim Meyering
2021-06-08  8:56             ` Bruno Haible
2021-06-09  0:41               ` Dmitry V. Levin
2021-06-10 20:05                 ` Bruno Haible
     [not found]             ` <CAH8yC8kHTq5J9onJj+2jwy_DwzXrwujqFs9TEBxGh5k_KCu=kg@mail.gmail.com>
2021-06-08 10:57               ` Bruno Haible
2021-06-08 16:42                 ` Paul Eggert
2021-06-09 13:35                   ` Dmitry V. Levin
2021-06-09 19:38                   ` Bruno Haible
2021-06-10 19:39                   ` Bruno Haible
2021-06-09  7:23                 ` Bernhard Voelker
2021-06-09 14:17                   ` Bruno Haible
2021-06-10  8:13                     ` Simon Josefsson via Gnulib discussion list
2021-06-10 19:51                       ` Bruno Haible
2021-06-10 21:49                         ` Simon Josefsson via Gnulib discussion list
2021-06-11 12:21                         ` Eric Blake
2021-06-11 13:57                           ` Bruno Haible
2021-06-19 12:02 ` new module 'sigsegv' Bruno Haible
2021-06-21 18:22   ` [PATCH] sigsegv, sigsegv-tests: Assign my contributions to the FSF Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2113844.jgEgOJX5uS@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=jim@meyering.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).