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

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: John Wiegley <jwiegley <at> gmail.com>, 20241 <at> debbugs.gnu.org,
 Artur Malabarba <bruce.connor.am <at> gmail.com>
Subject: Re: bug#20241: 25.0.50; `setq' with only one argument
Date: Wed, 25 Nov 2015 15:40:30 +0000

Hello, Drew.

On Wed, Nov 25, 2015 at 07:18:17AM -0800, Drew Adams wrote:
> > 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.

That would be the worst thing: it would leave the code possibly failing
exactly the way it did, but remove the evidence (which can be
mechanically found).

> 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.

Comments are less good than error messages from the byte compiler!

> 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.

I've just tried it out.  The byte compiler generates an error message,
but the .elc is written anyway.  No runtime error happens from such
compiled code.  But running it interpreted would signal an error.

> 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 currently doesn't do that.  I'm not convinced it should, either.

> 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.

Why is this topic suddenly seeming complicated?  :-(

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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