GNU bug report logs - #62009
29.0.60; Emacs crashes on setf symbol-name

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, michael_heerdegen <at> web.de, rpluim <at> gmail.com, monnier <at> iro.umontreal.ca, 62009 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: bug#62009: 29.0.60; Emacs crashes on setf symbol-name
Date: Fri, 10 Mar 2023 14:08:44 +0100

On 3/10/23 13:57, Eli Zaretskii wrote:
>> Date: Fri, 10 Mar 2023 13:45:11 +0100
>> Cc: philipk <at> posteo.net, michael_heerdegen <at> web.de, monnier <at> iro.umontreal.ca,
>>  62009 <at> debbugs.gnu.org, rpluim <at> gmail.com, arstoffel <at> gmail.com
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>>
>>> We disagree here, and this is a very fundamental disagreement, which
>>> basically means continuing this argument is pointless, since we have
>>> no common basis.
>>
>> I don't see that the disagreement is that strong. For example aset
>> signals an error if you try to access elements out of bounds.
>>
>> (aset "abc" 3 ?x) -> args-out-of-range
> 
> yes, because that's a frequent programmatic mistake.

Agree.

>> So there are clearly use cases where signaling an error is justified.
> 
> Of course.  It's just that the use case being discussed is not one of
> them.

I agree with you, that this is not a common mistake. But it is still a
mistake and we could easily protect the user from it.

This is a general question - do we want to prevent and catch most
programmer mistakes or not? You seem to lean on rather not catching some
errors which are rare and I am in favor of catching more errors if the
costs permit. In this case, the costs are small in my book (I cannot
look into your book and understand how you come to your conclusions).
Given that Robert already pointed out that objects can be marked as
read-only, all the necessary infrastructure is already in place, making
this a cheap change.

Catching more mistakes improves overall robustness of Emacs and
generally there are also security considerations which should be taken
into account. It may not matter in this case, but ensuring that the
Elisp runtime is memory safe as much as possible is a worthy goal.

>> In other cases you claim signaling an error is unjustified and a
>> crash is better.
> 
> I said nothing of the kind.  I said it was unjustified in the
> particular case which is being discussed here.

You clearly said that you object to any measures which fix this issue.
This means you prefer if Emacs crashes, instead of it signaling an error.

Daniel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.