GNU bug report logs - #61730
30.0.50; Compiler warnings for delq and delete

Previous Next

Full log

View this message in rfc822 format

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61730 <at> debbugs.gnu.org
Subject: bug#61730: 30.0.50; Compiler warnings for delq and delete
Date: Sun, 26 Feb 2023 22:24:27 -0500

  > In Emacs maintenance and development, the two cases are actually one.
  > We rebuild Emacs so frequently that even a "rare" warning appears all
  > the time and is annoying.  It is not a coincidence that we usually
  > don't tolerate warnings during the build of Emacs.

I am surprised -- I didn't do that when I was the main maintainer.  In
recent years, ISTR seeing warnings in the build often enough.

If you intend to make a change to prevent each such warning, that
implies that each spurious warning is a bigger pain in the neck.  That
makes a stronger argument for making fewer warnings rather than more.

I resent it when a compiler takes up my time pressuring me to prove to
it that I know something isn't a bug, and I usually tell that compiler
(inside my head) where it can take those warnings.

  > What's your opinion about the case of non-destructive functions - is it
  > ok if we would always warn about thrown away return values of calls of
  > them?

Either make it an optional feature (and disabled by default), or do
not implement them.

When I implemented the options that enable such warnings in GCC, I
urged people NOT to use those options by default.  To enable them by
default in a makefile is to impose systematic harassment on every
contributor to the code.  You end up with a program as your
taskmaster, haranguing you continually to insert proof that you didn't
make some mistake.

I never used those options.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.