bug#32979: 27.0.50; Oddity in #'keywordp comments.

[Eli Zaretskii]

> From: Aidan Kehoe <kehoea@parhasard.net>
> Date: Sun, 7 Oct 2018 23:03:25 +0100
> 
> /* Define this in C to avoid unnecessarily consing up the symbol
>    name.  */
> DEFUN ("keywordp", Fkeywordp, Skeywordp, 1, 1, 0,
>        doc: /* Return t if OBJECT is a keyword.
> This means that it is a symbol with a print name beginning with `:'
> interned in the initial obarray.  */)
>   (Lisp_Object object)
> {
>   if (SYMBOLP (object)
>       && SREF (SYMBOL_NAME (object), 0) == ':'
>       && SYMBOL_INTERNED_IN_INITIAL_OBARRAY_P (object))
>     return Qt;
>   return Qnil;
> }
> 
> It's completely reasonable to implement the #'keywordp predicate in C given
> the internal GNU Emacs approach to keywords. The equivalent Lisp
> implementation of:
> 
> (defun keywordp (object)
>   (and object (symbolp object) (eq ?: (aref (symbol-name object) 0))
>        (eq object (intern-soft (symbol-name object) obarray))))
> 
> involves a hash table lookup after a Lisp funcall, and checking #'keywordp
> should be cheap. The comment, however, has nothing to do with anything, there
> is no consing or other dynamic memory allocation at any point, neither in the
> obvious Lisp implementation, the old cl-compat.el implementation of 20.7, nor
> the current code. The comment should be removed.

I think the author of the code thought that symbol-name conses a
string.  (At some distant point in the past, aref worked in bytes, not
in characters, and the internal representation of text was not yet
superset of UTF-8, so we couldn't assume that if the first byte is
':', so is the first character, and needed to use substring instead.
But that was fixed a year before keywordp got coded in C, so that was
unlikely to be the reason for the comment.)

I removed the comment.  Thanks for bringing this to our attention.