bug#14565: 24.3.50; Error with byte-compiled function using backward-char

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Stephen Berman]

When I evaluate and invoke each of the following functions, they both
work as expected:

(defun my-test-1 () (forward-char nil))

(defun my-test-2 () (backward-char nil))

But if I byte-compile them, only my-test-1 works; my-test-2 raises a
Lisp error: (wrong-type-argument number-or-marker-p nil)

Here are the byte codes:

(byte-code "\300\301\302\"\207" [defalias my-test-1 #[nil "\300u\207" [nil] 1]] 3)

(byte-code "\300\301\302\"\207" [defalias my-test-2 #[nil "\300[u\207" [nil] 1]] 3)

and here is the disassembled code:

byte code for my-test-1:
  args: nil
0	constant  nil
1	forward-char 
2	return	  

byte code for my-test-2:
  args: nil
0	constant  nil
1	negate	  
2	forward-char 
3	return	  


In GNU Emacs 24.3.50.1 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
 of 2013-06-05 on rosalinde
Bzr revision: 112853 sdl.web@gmail.com-20130605074002-8mmjd1r5fvnb664v
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description:	openSUSE 12.2 (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Stephen Berman]

On Thu, 06 Jun 2013 16:24:17 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> When I evaluate and invoke each of the following functions, they both
> work as expected:
>
> (defun my-test-1 () (forward-char nil))
>
> (defun my-test-2 () (backward-char nil))
>
> But if I byte-compile them, only my-test-1 works; my-test-2 raises a
> Lisp error: (wrong-type-argument number-or-marker-p nil)
>
> Here are the byte codes:
>
> (byte-code "\300\301\302\"\207" [defalias my-test-1 #[nil "\300u\207" [nil] 1]] 3)
>
> (byte-code "\300\301\302\"\207" [defalias my-test-2 #[nil "\300[u\207" [nil] 1]] 3)
>
> and here is the disassembled code:
>
> byte code for my-test-1:
>   args: nil
> 0	constant  nil
> 1	forward-char 
> 2	return	  
>
> byte code for my-test-2:
>   args: nil
> 0	constant  nil
> 1	negate	  
> 2	forward-char 
> 3	return	  

If `negate' in the byte code corresponds to the case Bnegate in
exec_byte_code, then IIUC nil fails the test for INTEGERP so is passed
to Fminus, and from there to arith_driver, where it fails
CHECK_NUMBER_OR_FLOAT_COERCE_MARKER, which via CHECK_TYPE signals the
wrong-type-argument error.  If this is what happens, then the byte code
of backward-char is at odds with its definition via move_point in
cmds.c, which explicitly checks whether the argument is nil, and if so
sets it to 1, which for Fbackward_char is then negated.  Or have I
completely misunderstood and if so, what is the error due to?

Steve Berman

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Glenn Morris]

Version: 24.4

Thanks; fixed.

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Glenn Morris]

I suppose there could still be cases like

(setq foo nil)
(backward-char foo)

I wonder if these bytecomp handlers are worth keeping?

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Stephen Berman]

On Thu, 06 Jun 2013 22:28:22 -0400 Glenn Morris <rgm@gnu.org> wrote:

> I suppose there could still be cases like
>
> (setq foo nil)
> (backward-char foo)

Yes, in fact, after seeing your fix, I realized that I had
oversimplified my test case; the code which revealed the bug actually
looks more like this (still simplified, but enough to raise the error
with your fix):

(defun my-test-3 ()
  (let (x)
    (backward-char (when x 2))))

> I wonder if these bytecomp handlers are worth keeping?

I don't see how to tweak byte-compile-backward-char to account for the
above cases, but I don't understand the bytecomp code well.  However, I
did test adding a case Bbackward_char to exec_byte_code parallel to
Bforward_char, and that handles the above cases as expected.  So that
may be the easiest fix.

Steve Berman

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Stephen Berman]

On Fri, 07 Jun 2013 11:40:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 06 Jun 2013 22:28:22 -0400 Glenn Morris <rgm@gnu.org> wrote:
>
>> I suppose there could still be cases like
>>
>> (setq foo nil)
>> (backward-char foo)
>
> Yes, in fact, after seeing your fix, I realized that I had
> oversimplified my test case; the code which revealed the bug actually
> looks more like this (still simplified, but enough to raise the error
> with your fix):
>
> (defun my-test-3 ()
>   (let (x)
>     (backward-char (when x 2))))
>
>> I wonder if these bytecomp handlers are worth keeping?
>
> I don't see how to tweak byte-compile-backward-char to account for the
> above cases, but I don't understand the bytecomp code well.  However, I
> did test adding a case Bbackward_char to exec_byte_code parallel to
> Bforward_char, and that handles the above cases as expected.  So that
> may be the easiest fix.

Should this bug be reopened, or would you prefer me to submit a new
report for the unresolved cases?

Steve Berman

bug#14565: 24.3.50; Error with byte-compiled function using backward-char

[Stephen Berman]

On Sat, 08 Jun 2013 15:20:20 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Fri, 07 Jun 2013 11:40:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> On Thu, 06 Jun 2013 22:28:22 -0400 Glenn Morris <rgm@gnu.org> wrote:
>>
>>> I suppose there could still be cases like
>>>
>>> (setq foo nil)
>>> (backward-char foo)
>>
>> Yes, in fact, after seeing your fix, I realized that I had
>> oversimplified my test case; the code which revealed the bug actually
>> looks more like this (still simplified, but enough to raise the error
>> with your fix):
>>
>> (defun my-test-3 ()
>>   (let (x)
>>     (backward-char (when x 2))))
>>
>>> I wonder if these bytecomp handlers are worth keeping?
>>
>> I don't see how to tweak byte-compile-backward-char to account for the
>> above cases, but I don't understand the bytecomp code well.  However, I
>> did test adding a case Bbackward_char to exec_byte_code parallel to
>> Bforward_char, and that handles the above cases as expected.  So that
>> may be the easiest fix.
>
> Should this bug be reopened, or would you prefer me to submit a new
> report for the unresolved cases?

I just saw that you already took care of these cases; thanks.

Steve Berman