Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione]

On 01/03/2016 10:51 AM, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Sun, 3 Jan 2016 10:24:26 -0800
>>
>>> Robustness comes at a price.  You are asking Emacs and its users to
>>> pay a heavy price that they don't need to pay, because there are no
>>> requirements for Emacs to be as robust as safety-critical software.
>>
>> It's not a heavy price at all.
> 
> Yes, it is.  You would like us to crash rather than try recovering.
> That is a very heavy price in Emacs.

Why is it uniquely unacceptable in Emacs? Why do other programs that
fill the same niche not employ this strategy? Why do we not try to
mitigate NULL pointer dereferences (to which all the same arguments apply)?

You haven't addressed any of these points.

>>> Only if you think about Emacs as safety-critical piece of software
>>> that must operate continuously, 24x7.  Otherwise, memory leaks when
>>> recovering from a disaster that happens very rarely is quite
>>> acceptable, if it brings other benefits (such as not losing work).
>>
>> My point isn't that memory leaks are disastrous. It's that the
>> consequences of this code weren't given due consideration at the time it
>> was committed.
> 
> You have absolutely no evidence that this wasn't considered.  It's
> factually incorrect.  You don't have to know that it's incorrect, but
> I would expect you to give more credit to our collective knowledge and
> experience than you evidently do.

I searched the mailing list and saw no discussion of the points I
raised. The rebuttals to my concerns ("so what if some memory leaks?",
"emacs has longjmped from arbitrary points forever") have been
inadequate and incorrect.

>>> You are not objective, so you exaggerate the risks and dismiss the
>>> benefits.
>>
>> I disagree that there *are* significant benefits.
> 
> Of course, you do.  Like I said: your bias affects your judgment.

So does yours.

> 
>>>> *Anything* can happen, and there's no guarantee that what happens is
>>>> better for the user than an immediate crash. Hell, you can even cause
>>>> security problems with schemes of this sort.
>>>
>>> Sorry, that's FUD.
>>
>> No it isn't. When you invoke undefined behavior, anything unpleasant can
>> happen, and at scale, everything unpleasant will.
> 
> It's not undefined behavior, not in practice.  We know quite well what
> can and cannot happen.

No you don't, because we can longjmp out of third-party code, and unless
you have a crystal ball, you're not going to be able to predict
everything that code can do. That we know what can happen here is simply
false.

> 
> Anyway, saying that "unpleasant things can happen" _is_ FUD.  I want
> to see a single bug report about these unpleasant things happening in
> real use, then I'll start thinking whether I should reconsider.

And I want to see a real bug report about the stack overflow we're
trying to defend against. The failure mode here wouldn't be obvious
either: Emacs could just silently crash, hang, or write a wrong byte or
two to a file.

You have no idea what might happen, which is especially concerning
because Emacs is frequently an internet-facing network program parsing
untrusted data.

signature.asc
Description: OpenPGP digital signature