GNU bug report logs - #20241
25.0.50; `setq' with only one argument

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>, Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: John Wiegley <jwiegley <at> gmail.com>, 20241 <at> debbugs.gnu.org
Subject: RE: bug#20241: 25.0.50; `setq' with only one argument
Date: Wed, 25 Nov 2015 07:18:17 -0800 (PST)

> If you found four occurrences merely by grepping, there could well be
> quite a few more.  In the last one, for example, can we be sure that nil
> is intended, not that the real argument has just been missed out?

If you cannot now analyze the code properly to determine TRT, or
contact the author to make that determination, then do the obvious
(IMO): Assign a `nil' value explicitly where it is now assigned
implicitly.

AND flag that amended code with a comment saying what you've done,
and that you don't currently know whether (a) there is a bug here
or (b) `nil' is really what is needed.

IOW: (1) At least just ensure that the code does the same thing
that it does now, but respects the intended meaning of `setq'.
(2) If you have to punt the careful analysis for later or for
someone else, then add a comment to that effect.

> Maybe having the byte compiler error out in this situation isn't such a
> brilliant idea after all.

IMO, the bug should be fixed to raise an _error at runtime_, for
both interpreted and byte-compiled code.

Whatever else the byte-compiler might do is less important, as
long as it produces code that is comparable - e.g., code that
will also raise an _error at runtime_.

It's OK for a byte-compiler to be smart, but not smarter than
the actual source code ;-).  It should pretty much try to
produce code that does the same thing, but hopefully usually
does it quicker.

Previous Next

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