Undefined behavior for the function ‘last’ or an error?

Undefined behavior for the function ‘last’ or an error?

[tpeplt]

The built-in Emacs Lisp function ‘last’ accepts a list as its argument:

(last '(a b c)) => (c)

It also (surprisingly) accepts a non-list as its argument:

(last 'a) => a
(last 3.14) => 3.14
(last "string of chars") => "string of chars"

Contrast this with ‘butlast’ and ‘nbutlast’:

(butlast 'a)
*** Eval error ***  Wrong type argument: sequencep, a
(butlast 3.14)
*** Eval error ***  Wrong type argument: sequencep, 3.14
(butlast "string of chars")
*** Eval error ***  Wrong type argument: listp, "string of chars"

Is this behavior by ‘last’ an error, is it correct and undocumented, or
is it correct and documented in some obscure (to me) location?

Below are the docstring for ‘last’ and the entry in the elisp reference
manual.  Neither mentions this behavior by ‘last’.

Docstring for ‘last’:

(last LIST &optional N)

Return the last link of LIST.  Its car is the last element.
If LIST is nil, return nil.
If N is non-nil, return the Nth-to-last link of LIST.
If N is bigger than the length of LIST, return LIST.

From (info "(elisp) List Elements"):

 -- Function: last list &optional n
     This function returns the last link of LIST.  The ‘car’ of this
     link is the list’s last element.  If LIST is null, ‘nil’ is
     returned.  If N is non-‘nil’, the Nth-to-last link is returned
     instead, or the whole of LIST if N is bigger than LIST’s length.

--

Re: Undefined behavior for the function ‘last’ or an error?

[tpeplt]

Forgot to mention -- these results are from Emacs version 29.3.

Start emacs from a shell prompt with "emacs -Q" to avoid any
re-definition of ‘last’.

> The built-in Emacs Lisp function ‘last’ accepts a list as its argument:
>
> (last '(a b c)) => (c)
>
> It also (surprisingly) accepts a non-list as its argument:
>
> (last 'a) => a
> (last 3.14) => 3.14
> (last "string of chars") => "string of chars"
>

--

RE: [External] : Undefined behavior for the function ‘last’ or an error?

[Drew Adams]

> The built-in Emacs Lisp function ‘last’ accepts
> a list as its argument:
> 
> (last '(a b c)) => (c)
> 
> It also (surprisingly) accepts a non-list as its argument:
> 
> (last 'a) => a
> (last 3.14) => 3.14
> (last "string of chars") => "string of chars"

Congratulations!

This regression was introduced in Emacs 24.5.
Prior to that it would raise an error.

In 24.5 `safe-length' was substituted for
`length', and that results in what you see.

(`C-h f safe-length'.)

IMO this should be fixed.  Someone(TM) will
maybe say it's intentional (but then it
should be doc'd).

`safe-length' is good, in avoiding pbs with
circular lists etc.  But either some test
for a list (or a sequence) should be used
or this nontraditional behavior for `last'
should be doc'd.  (`last' should of course
work with dotted lists.)

`last' is one of the oldest Lisp functions.
We really shouldn't be fiddling with its
behavior in unexpected ways.

Re: [External] : Undefined behavior for the function ‘last’ or an error?

[tpeplt]

Drew Adams <drew.adams@oracle.com> writes:

>
> IMO this should be fixed.  Someone(TM) will
> maybe say it's intentional (but then it
> should be doc'd).
>

Also, if it is intentional, then it should be documented why it is
inconsistent with how the related functions ‘butlast’ and ‘nbutlast’
behave so that users do not expect those two functions to accept
non-lists as an argument.

Also, checking a few other list functions, ‘nthcdr’, ‘take’, and
‘ntake’, there is a similar inconsistent result that might be
intentional or not.  The behavior of ‘nthcdr’ is unexpected, while the
behavior of ‘take’ and ‘ntake’ are unpredictable because these are
Emacs-Lisp-specific functions.

(nthcdr 0 'a) => a

(nthcdr 1 'a) => a
*** Eval error ***  Wrong type argument: listp, a

(take 0 'a) => nil

(take 1 'a) => nil
*** Eval error ***  Wrong type argument: listp, a

(ntake 0 'a) => nil

(ntake 1 'a) => nil
*** Eval error ***  Wrong type argument: listp, a

--

RE: [External] : Undefined behavior for the function ‘last’ or an error?

[Drew Adams]

> > IMO this should be fixed.  Someone(TM) will
> > maybe say it's intentional (but then it
> > should be doc'd).
> 
> Also, if it is intentional, then it should be documented why it is
> inconsistent with how the related functions ‘butlast’ and ‘nbutlast’
> behave so that users do not expect those two functions to accept
> non-lists as an argument.
> 
> Also, checking a few other list functions, ‘nthcdr’, ‘take’, and
> ‘ntake’, there is a similar inconsistent result that might be
> intentional or not.  The behavior of ‘nthcdr’ is unexpected, while the
> behavior of ‘take’ and ‘ntake’ are unpredictable because these are
> Emacs-Lisp-specific functions.

I suggest you do: `M-x report-emacs-bug'.
Thanks for uncovering this.

Re: [External] : Undefined behavior for the function ‘last’ or an error?

[tpeplt]

Drew Adams <drew.adams@oracle.com> writes:

>> > IMO this should be fixed.  Someone(TM) will
>> > maybe say it's intentional (but then it
>> > should be doc'd).
>> 
>> Also, if it is intentional, then it should be documented why it is
>> inconsistent with how the related functions ‘butlast’ and ‘nbutlast’
>> behave so that users do not expect those two functions to accept
>> non-lists as an argument.
>> 
>> Also, checking a few other list functions, ‘nthcdr’, ‘take’, and
>> ‘ntake’, there is a similar inconsistent result that might be
>> intentional or not.  The behavior of ‘nthcdr’ is unexpected, while the
>> behavior of ‘take’ and ‘ntake’ are unpredictable because these are
>> Emacs-Lisp-specific functions.
>
> I suggest you do: `M-x report-emacs-bug'.
> Thanks for uncovering this.

Thanks for the response.  I will wait a day to see if anyone can point
to something I have missed.  If no one does, then I will report the
problem.

--

Re: [External] : Undefined behavior for the function ‘last’ or an error?

[tpeplt]

Drew Adams <drew.adams@oracle.com> writes:

>
>>
>> I suggest you do: `M-x report-emacs-bug'.
>> Thanks for uncovering this.
>
> Thanks for the response.  I will wait a day to see if anyone can point
> to something I have missed.  If no one does, then I will report the
> problem.
>
> --

There have been no additional responses to this.  This issue has been
now been reported.  It has been assigned bug #70155
(70155@debbugs.gnu.org).

--