Re: Crashes in "C-h h"

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Fri, 5 Jul 2019 08:17:39 +0000
> Cc: address@hidden, address@hidden
> 
> > Parse error.  What is "f", what is "g", where should I insert
> > "again".  Maybe ENOCOFFEE.
> 
> int
> noop (Lisp_Object x, ptrdiff_t n)
> {
>   return 0;
> }
> 
> int
> f (Lisp_Object x, ptrdiff_t n)
> {
>   return FIXNUMP (x) && XFIXNUM (x) == n;
> }
> 
> int
> g (Lisp_Object x, ptrdiff_t n)
> {
>   return EQ (x, make_fixnum (n));
> }

So you expected me to remember the function names by heart? ;-)

> Using "g" is about 8 seconds slower than "noop". Using "f" is about 85
> seconds slower than "noop". Using "f" is about 76 seconds slower than
> "g".

It is not useful to compare to a function that does nothing.  Useful
comparisons would be with functions that do this:

  return x == y;

or this:

  return XFIXNUM (a) == y;

where x and y are int's and a is a fixnum.

> we all agree that EQ (x, make_fixnum (n)) is the right thing to do if
> you are certain n is in the fixnum range.

That's not my conclusion.  (And if N is not in the fixnum range, why
would you call make_fixnum for it?)

My conclusion is that comparing with make_fixnum, i.e.

    EQ (x, make_fixnum (n))

is TRT when you are NOT certain that X is a fixnum, especially when
the comparison is done in a loop against many different values of X
and only one value of N, in which case make_fixnum can be called
outside of the loop.

If you ARE certain that X is a fixnum, then

    XFIXNUM (x) == n

is also OK.

The comparison with

    if (FIXNUMP (x) && XFIXNUM (x) == n)

is IMO not useful, because it should be clear up front that it will
always lose due to the additional test.