Re: RE_TRANSLATE_P

[Kim F. Storm]

Richard Stallman <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>

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