unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Undefined behavior for the function ‘last’ or an error?
@ 2024-04-01 16:53 tpeplt
  2024-04-01 17:12 ` tpeplt
  2024-04-01 17:28 ` [External] : " Drew Adams
  0 siblings, 2 replies; 7+ messages in thread
From: tpeplt @ 2024-04-01 16:53 UTC (permalink / raw)
  To: help-gnu-emacs

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.

--



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Undefined behavior for the function ‘last’ or an error?
  2024-04-01 16:53 Undefined behavior for the function ‘last’ or an error? tpeplt
@ 2024-04-01 17:12 ` tpeplt
  2024-04-01 17:28 ` [External] : " Drew Adams
  1 sibling, 0 replies; 7+ messages in thread
From: tpeplt @ 2024-04-01 17:12 UTC (permalink / raw)
  To: help-gnu-emacs

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"
>

--



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [External] : Undefined behavior for the function ‘last’ or an error?
  2024-04-01 16:53 Undefined behavior for the function ‘last’ or an error? tpeplt
  2024-04-01 17:12 ` tpeplt
@ 2024-04-01 17:28 ` Drew Adams
  2024-04-01 18:35   ` tpeplt
  1 sibling, 1 reply; 7+ messages in thread
From: Drew Adams @ 2024-04-01 17:28 UTC (permalink / raw)
  To: tpeplt, help-gnu-emacs@gnu.org

> 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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [External] : Undefined behavior for the function ‘last’ or an error?
  2024-04-01 17:28 ` [External] : " Drew Adams
@ 2024-04-01 18:35   ` tpeplt
  2024-04-01 19:25     ` Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: tpeplt @ 2024-04-01 18:35 UTC (permalink / raw)
  To: Drew Adams; +Cc: help-gnu-emacs@gnu.org

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

--



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [External] : Undefined behavior for the function ‘last’ or an error?
  2024-04-01 18:35   ` tpeplt
@ 2024-04-01 19:25     ` Drew Adams
  2024-04-01 20:11       ` tpeplt
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2024-04-01 19:25 UTC (permalink / raw)
  To: tpeplt; +Cc: help-gnu-emacs@gnu.org

> > 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [External] : Undefined behavior for the function ‘last’ or an error?
  2024-04-01 19:25     ` Drew Adams
@ 2024-04-01 20:11       ` tpeplt
  2024-04-03  1:05         ` tpeplt
  0 siblings, 1 reply; 7+ messages in thread
From: tpeplt @ 2024-04-01 20:11 UTC (permalink / raw)
  To: Drew Adams; +Cc: help-gnu-emacs@gnu.org

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.

--



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [External] : Undefined behavior for the function ‘last’ or an error?
  2024-04-01 20:11       ` tpeplt
@ 2024-04-03  1:05         ` tpeplt
  0 siblings, 0 replies; 7+ messages in thread
From: tpeplt @ 2024-04-03  1:05 UTC (permalink / raw)
  To: Drew Adams; +Cc: help-gnu-emacs@gnu.org


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).

--



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-04-03  1:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-01 16:53 Undefined behavior for the function ‘last’ or an error? tpeplt
2024-04-01 17:12 ` tpeplt
2024-04-01 17:28 ` [External] : " Drew Adams
2024-04-01 18:35   ` tpeplt
2024-04-01 19:25     ` Drew Adams
2024-04-01 20:11       ` tpeplt
2024-04-03  1:05         ` tpeplt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).