Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Sun, 3 Jan 2016 11:04:08 -0800
> 
> > 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?

Not many other programs run for so long and have so much precious data
for their users.  Besides, who says there are no other programs that
do this?  libsigsegv wasn't written as an academic exercise.

> Why do we not try to mitigate NULL pointer dereferences (to which
> all the same arguments apply)?

We do: we catch SIGSEGV and try to save what can be salvaged.

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

Who said that considerations must be in public discussions?  On the
contrary, I'd rather take the lack of discussions as an indication
that this was considered and no one saw any problem with it.

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

No, I acknowledge the risks.  You don't acknowledge the benefits.

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

FUD.  What "third-party code"?  Any code we use in Emacs has its
sources open for scrutiny.

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

We've been through that already: if stack overflow never happens, the
recovery code can never cause any problems.

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

Neither of which is a disaster.

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

All I want is to take every measure to avoid losing work.  Every other
problem was already there before stack-overflow recovery was added.