Daniel Colascione wrote:
> It's *critical* not to violate the invariants of code.

Sure, but we are discussing what those invariants should be; they are not carved 
in stone.  One possible invariant is (A) "stack overflow never happens". Another 
is (B) "if stack overflow happens, callers must tolerate being longjmped 
through". Either invariant is reasonable per se. It is a judgment call as to 
which invariant is better for Emacs. Possibly some modules will prefer (A) and 
others (B).

Take the regular expression code as an example. Suppose it has unusual 
worst-case behavior that can grow the stack in arbitrary ways (which I think it 
does though I'm not going to investigate the details right now). One way to 
address this is to rewrite the code so that it doesn't have the behavior, but 
that would be a pain; the code has been that way for decades and is crufty at 
this point and a lot of Emacs depends on its quirks. Another way to address it 
is to use a guard page or whatever on the halfway-decent platforms that support 
that sort of thing. We've chosen the latter, i.e., we've chosen invariant (B), 
and yes there are problems with this approach but it beats doing nothing and it 
beats doing (A) because nobody has had the time to do (A), assuming it's doable 
at all.

> It should be possible to replace the printfs
> in this instance with calls to write(1, "message") (which will bypass
> any output buffering) and restore async-signal-safety.

Good point. I did that with the attached patch to emacs-25. However, this 
doesn't address the Fdo_auto_save () issue in the same neighborhood.

> If a user elects to attempt auto-save in this situation, that's on him.

Sure, and Emacs already asks the user whether to auto-save in that situation, so 
this should be OK already.

> Ideally, we'd make autosave async-signal-safe, which will help in this
> handler and in the segfault hander.

Yes, that'd be good, if we didn't lose functionality thereby.