bug#62009: 29.0.60; Emacs crashes on setf symbol-name

[Eli Zaretskii]

> Date: Fri, 10 Mar 2023 14:08:44 +0100
> Cc: philipk@posteo.net, michael_heerdegen@web.de, monnier@iro.umontreal.ca,
>  62009@debbugs.gnu.org, rpluim@gmail.com, arstoffel@gmail.com
> From: Daniel Mendler <mail@daniel-mendler.de>
> 
> >> (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.

I don't agree with "easily".  And I think "not common" is an
understatement.

> This is a general question - do we want to prevent and catch most
> programmer mistakes or not?

Depends on the mistakes and the price.

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

We disagree about the importance of the mistake, and we disagree about
the costs of handling it.

In addition to the runtime costs, in terms of CPU and memory/GC,
there's also the aspect of introducing into Emacs a feature that we
will have to support for the observable future.  What if we want at
some point to change how these strings are store, and that change
makes these mistakes even harder to support?  We are taking upon
ourselves an obligation that we could regret, for the benefit of silly
code that shouldn't be written in the first place.  That kind of
trade-off makes no sense.

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

The disagreement is not about principles, it's about this particular
case.

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

That's your conclusion, not something I said.  What I did say is that
the nature and the rarity of the issue do not justify the costs.