RE_TRANSLATE_P

RE_TRANSLATE_P

[Eli Zaretskii]

A recent change to src/config.in changed the definition of
RE_TRANSLATE_P to this:

    #define RE_TRANSLATE_P(TBL) (!EQ (TBL, make_number (0)))

whereas before the change it simply called XFASTINT.

This causes RE_TRANSLATE_P to invoke a function, at least if compilers
other than GCC are used.  I wonder why replacing XFASTINT with XINT
was not enough to fix the original problem?

Re: RE_TRANSLATE_P

[Richard Stallman]

    This causes RE_TRANSLATE_P to invoke a function, at least if compilers
    other than GCC are used.  I wonder why replacing XFASTINT with XINT
    was not enough to fix the original problem?

Would this make it right?

*** config.in	23 Nov 2004 11:44:45 -0500	1.203
--- config.in	29 Nov 2004 00:30:17 -0500	
***************
*** 969,975 ****
--- 969,979 ----
  /* Tell regex.c to use a type compatible with Emacs.  */
  #define RE_TRANSLATE_TYPE Lisp_Object
  #define RE_TRANSLATE(TBL, C) CHAR_TABLE_TRANSLATE (TBL, C)
+ #ifdef __GCC__
  #define RE_TRANSLATE_P(TBL) (!EQ (TBL, make_number (0)))
+ #else
+ #define RE_TRANSLATE_P(TBL) (!(INTEGERP (TBL) && XINT (TBL) == 0))
+ #endif
  #endif
  
  /* Avoid link-time collision with system mktime if we will use our own.  */

Re: RE_TRANSLATE_P

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     This causes RE_TRANSLATE_P to invoke a function, at least if compilers
>     other than GCC are used.  I wonder why replacing XFASTINT with XINT
>     was not enough to fix the original problem?
>
> Would this make it right?

It seems like that change was made in several places, so perhaps
we should have a ZEROP macro to test such cases in a portable
manner.  

It would also make the code cleaner:

ZEROP (obj)

is much easier to understand at a glance than

EQ (obj, make_number (0))


A possible definition would be:

#ifdef __GCC__
#define ZEROP(obj) (!EQ ((obj), make_number (0)))
#else
#define ZEROP(obj) (!(INTEGERP ((obj)) && XINT ((obj)) == 0))
#endif

But the second form evals 'obj' twice, so we need a BIG FAT WARNING
when using ZEROP, or find some other portable way to implement it.


I could make that change.

>
> *** config.in	23 Nov 2004 11:44:45 -0500	1.203
> --- config.in	29 Nov 2004 00:30:17 -0500	
> ***************
> *** 969,975 ****
> --- 969,979 ----
>   /* Tell regex.c to use a type compatible with Emacs.  */
>   #define RE_TRANSLATE_TYPE Lisp_Object
>   #define RE_TRANSLATE(TBL, C) CHAR_TABLE_TRANSLATE (TBL, C)
> + #ifdef __GCC__
>   #define RE_TRANSLATE_P(TBL) (!EQ (TBL, make_number (0)))
> + #else
> + #define RE_TRANSLATE_P(TBL) (!(INTEGERP (TBL) && XINT (TBL) == 0))
> + #endif
>   #endif
>   
>   /* Avoid link-time collision with system mktime if we will use our own.  */
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: RE_TRANSLATE_P

[Richard Stallman]

    It seems like that change was made in several places, so perhaps
    we should have a ZEROP macro to test such cases in a portable
    manner.  

That would be a natural extension if it had no problems.
But as you pointed out, it has a problem:

    But the second form evals 'obj' twice, so we need a BIG FAT WARNING
    when using ZEROP, or find some other portable way to implement it.

So let's not replace an easy change with a hard one.  The specific
change I suggested has no problem, because RE_TRANSLATE_P is used only
with variables as arguments.