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

Previous Next

Full log

Message #26 received at 61730 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: mattias.engdegard <at> gmail.com, 61730 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61730: 30.0.50; Compiler warnings for delq and delete
Date: Fri, 24 Feb 2023 17:48:03 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: mattias.engdegard <at> gmail.com,  61730 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Fri, 24 Feb 2023 16:45:18 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Not in my opinion.  I'm sick and tired from seeing compilers emitting
> > bogus warnings which require one to spend time verifying perfectly
> > correct code, or, worse, modify the code to shut up the compiler.  Do
> > we really want to see stuff like
> >
> >   (setq _ (delq ...))
> >
> > in our code?
> 
> That's a bit of an exaggeration: the code would just look like in the
> thousands of other cases where we are not sure whether the element to
> delete is not at the head, like
> 
>   (setq my-list (delq elt my-list))
> 
> which is not worse, even better readable IMO, than a naked `delq'
> call.

Even though my-list is never used again in the program?  How is this
better than "(setq _ ..."?

> > If it's really impossible (and I'm not sure it is), then the better
> > course of action is to emit the warnings only if the byte compiler was
> > requested to be more sensitive to potential issues, similar to GCC's
> > "-W*" options.  IOW, if someone wants to lint their code, let them ask
> > for a linting compilation.
> 
> But I would be okay with that.

Great, thanks.

Previous Next

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