Re: Compiling Elisp to a native code with a GCC plugin

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <address@hidden>
> Date: Fri, 17 Sep 2010 19:30:52 +0200
> 
> Right.  Things like 
> 
>       int pt = PT;
> 
> in buffer.c is easy enough, but is the following (from insdel.c)
> correct?  
> 
>       int b = XINT (Fmarker_position (current_buffer->mark));

I think it's a bug, should use "EMACS_INT b".

>       int e = XINT (make_number (PT));
> 
> I don't really understand the last line at all.  It first creates a
> Lisp_Object number from PT, and then gets the C-level EMACS_INT value
> from that again?  And then casts it to an int? 

I think it's a bug, should use "EMACS_INT e = PT;"

As for why it converts it to Lisp integer and then back to a C
EMACS_INT: it seems to be a historical curiosity.  Revision 101018
made this change:

 === modified file 'src/insdel.c'
 --- src/insdel.c        2010-08-07 19:39:04 +0000
 +++ src/insdel.c        2010-08-07 20:26:55 +0000
 @@ -2055,13 +2055,12 @@ prepare_to_modify_buffer (EMACS_INT star
        && !NILP (Vtransient_mark_mode)
        && NILP (Vsaved_region_selection))
      {
 -      Lisp_Object b = Fmarker_position (current_buffer->mark);
 -      Lisp_Object e = make_number (PT);
 -      if (NILP (Fequal (b, e)))
 -       {
 -         validate_region (&b, &e);
 -         Vsaved_region_selection = make_buffer_string (XINT (b), XINT (e), 0);
 -       }
 +      int b = XINT (Fmarker_position (current_buffer->mark));
 +      int e = XINT (make_number (PT));
 +      if (b < e)
 +       Vsaved_region_selection = make_buffer_string (b, e, 0);
 +      else if (b > e)
 +       Vsaved_region_selection = make_buffer_string (e, b, 0);
      }

I guess the change mechanically used XINT to move the comparison to
C-level integers, but didn't pay attention to the fact that it would
be easier to just remove the make_number call and use PT directly.

Chong, did I miss something?