all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,
	 stefankangas@gmail.com, adam@alphapapa.net,
	 arthur.miller@live.com
Subject: Re: Declaring Lisp function types
Date: Thu, 02 May 2024 06:12:42 -0400	[thread overview]
Message-ID: <yp1y18s4j51.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <8634r0oi2h.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 May 2024 09:15:34 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,
>>   stefankangas@gmail.com,  adam@alphapapa.net,  arthur.miller@live.com
>> Date: Wed, 01 May 2024 16:57:58 -0400
>>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>> > Thanks Eli for reminding me: as mentioned earlier, I think we should
>> > clarify what are the possible consequences if a type does not faithfully
>> > reflect the behavior of the function.  Examples of questions that one
>> > should be able to answer based on the doc:
>> >
>> > - Can an incorrect type affect Emacs' behavior (other than performance)?
>> > - And if so, can it cause a crash?
>> > - What if the type is/was right but an advice does
>> >   not obey the original type of the advised function?
>> >
>> > The doc doesn't need to answer those questions directly, but it should
>> > describe the possible effects of type annotations in enough details that
>> > we can answer those questions.
>>
>> Thanks, I think it should be more clear now.  I don't think we want to
>> be over specific there as what the implementation does when the
>> 'promise' of the declaration is not respected might change in the
>> future.
>
> The text you added says an incorrect type produces undefined behavior.
> Is that true for all alternatives of calling the function:
> interpreted, byte-compiled, and native-compiled, or only with some of
> these?

AFAIK only native-compiled ATM.  Do you think we should specify that?

> "Undefined behavior" sounds scary, and I wonder whether it is really
> accurate.  If the practical expressions of this UB are only some
> specific ones, perhaps we should mention them?  For example, UB
> generally means your entire system could be brought down, but I very
> much doubt that this could happen due to incorrect type declaration,
> could it?

There are probably very few cases that can cause this (ATM I could think
only of one) but if one pokes at that is actually not that difficult:

(defun foo ()
  (declare (type (function () cons)))
  3)

(defun bar ()
  (car (foo)))

Compiling this code and calling car crashes my Emacs.

PS We might want to control this in the future adding a compilation
parameter 'safety'.

  Andrea



  reply	other threads:[~2024-05-02 10:12 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 16:02 Declaring Lisp function types Andrea Corallo
2024-02-23 23:35 ` Adam Porter
2024-02-24  7:10   ` Eli Zaretskii
2024-02-24  8:53     ` Tomas Hlavaty
2024-02-24  9:08       ` Adam Porter
2024-02-24  9:24         ` Andrea Corallo
2024-02-24 15:13           ` Tomas Hlavaty
2024-02-24 15:21             ` Tomas Hlavaty
2024-02-24 15:24               ` Tomas Hlavaty
2024-02-24  8:56     ` Adam Porter
2024-02-24 10:03       ` Eli Zaretskii
2024-02-25  7:35         ` Adam Porter
2024-02-24  9:21   ` Andrea Corallo
2024-02-25 17:04 ` Alan Mackenzie
2024-02-25 17:15   ` Eli Zaretskii
2024-02-25 17:16   ` [External] : " Drew Adams
2024-02-26 16:25   ` Andrea Corallo
2024-02-29  3:50   ` Richard Stallman
2024-02-29  6:10     ` Adam Porter
2024-02-29  9:02     ` Andrea Corallo
2024-02-26  3:38 ` Richard Stallman
2024-02-26 16:38   ` [External] : " Drew Adams
2024-02-26 16:54     ` Eli Zaretskii
2024-02-26 17:44       ` Andrea Corallo
2024-02-26 16:52   ` Andrea Corallo
2024-02-26 18:10     ` Tomas Hlavaty
2024-03-02 21:19 ` Stefan Monnier via Emacs development discussions.
2024-03-03  9:52   ` Andrea Corallo
2024-03-03 14:52     ` Stefan Monnier
2024-03-03 17:31       ` Andrea Corallo
2024-03-03 18:13         ` Stefan Monnier
2024-03-15 16:49 ` Andrea Corallo
2024-03-15 18:19   ` Tomas Hlavaty
2024-03-15 18:38     ` Eli Zaretskii
2024-03-16 13:39       ` Tomas Hlavaty
2024-03-16 14:06         ` Eli Zaretskii
2024-03-16 14:56           ` Tomas Hlavaty
2024-03-16 15:43             ` Emanuel Berg
2024-03-16 15:44             ` Eli Zaretskii
2024-03-16 15:54               ` Emanuel Berg
2024-03-18  8:55               ` Lele Gaifax
2024-03-16  0:01   ` Adam Porter
2024-03-18  9:25     ` Andrea Corallo
2024-03-26 10:13   ` Andrea Corallo
2024-03-26 10:28     ` Christopher Dimech
2024-03-26 12:55     ` Eli Zaretskii
2024-03-26 16:46       ` Andrea Corallo
2024-04-29 17:48         ` Andrea Corallo
2024-04-29 17:55           ` Stefan Monnier
2024-04-29 18:42             ` Andrea Corallo
2024-04-30 14:55           ` Eli Zaretskii
2024-04-30 18:29             ` Stefan Monnier
2024-05-01 20:57               ` Andrea Corallo
2024-05-01 21:06                 ` Stefan Monnier
2024-05-02  6:16                   ` Eli Zaretskii
2024-05-02 10:16                   ` Andrea Corallo
2024-05-02  6:15                 ` Eli Zaretskii
2024-05-02 10:12                   ` Andrea Corallo [this message]
2024-05-02 11:15                     ` Eli Zaretskii
2024-05-02 13:20                     ` Stefan Monnier
2024-05-01 20:54             ` Andrea Corallo
2024-05-02 10:22               ` Eli Zaretskii
2024-05-02 15:18                 ` Andrea Corallo
2024-05-02 16:32                   ` Eli Zaretskii
2024-03-26 13:05     ` Mattias Engdegård
2024-03-26 13:44     ` Stefan Monnier
2024-03-26 14:28     ` Joost Kremers
2024-03-26 14:37       ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2024-03-16  7:46 Arthur Miller
2024-03-16 15:46 ` Emanuel Berg
2024-03-18  9:02 ` Andrea Corallo
2024-03-18  9:58   ` Arthur Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yp1y18s4j51.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=adam@alphapapa.net \
    --cc=arthur.miller@live.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.