On 01/03/2016 09:16 AM, Eli Zaretskii wrote: >> From: Paul Eggert >> Date: Sun, 3 Jan 2016 08:31:35 -0800 >> >> Daniel Colascione wrote: >>> In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to >>> detect C stack oerflow and longjmp back to toplevel. It's important to >>> note that we don't just longjmp when we're in a safe position: we >>> longjmp from *anywhere*, even if we're, say, in the middle of malloc. >> >> Although that particular code path may have been introduced recently, for >> decades Emacs has longjmped from arbitrary locations due to other signals, so >> adding a longjmp for SIGSEGV does not introduce new issues. >> >>> The code is fundamentally flawed and cannot be made to work >>> properly on any platform. >> >> The code is part of Emacs 24.5 and does not appear to be causing problems; at >> least, I don't recall any bug reports from the field. The other longjmps, which >> are fundamentally flawed in the same way, have been in Emacs for decades, and >> also seem to work well enough in practice. > > All true. Untrue. Which jumps in particular can come from inside malloc? > But we are reiterating a long discussion, where all of this was > already said, and said again, and again, and again. There's nothing > new left to be said here. > > Daniel thinks that Emacs should be designed and implemented as > safety-critical software, where any such techniques are a definite > no-no. But Emacs is not a safety-critical program, it is allowed to > crash from time to time, even in nasty ways. It is therefore okay for > such a program to use techniques that make the probability of losing > work lower. My analysis of this discussion is that this is the > crucial point that Daniel refuses to understand and/or agree to -- > that being a non safety-critical piece of software means Emacs can do > stuff that it otherwise would have been prohibited from doing. It's not about whether Emacs is "safety critical" --- it's about whether you're making the robustness situation worse than it already is by adding dubious workarounds for a problem we don't actually have. The Linux kernel doesn't bill itself as safety critical either, and this kind of reckless sloppiness wouldn't be acceptable there either. > IOW, a requirement as fundamental as safety-criticality _does_ affect > the design and the techniques allowed during implementation. I submit > that this is a fundamental software engineering issue which cannot be > cast away, and as long as Daniel misinterprets it, we can never agree > on anything. Because in safety-critical software, even a single nasty > crash can be fatal, something that is very far from what Emacs can do. You're creating a false dichotomy between safety-critical software and everything else. Emacs merely not avionics-grade software does not excuse the use of techniques that are both inherently incorrect and that add no real value and quite a bit of real danger. You have *still* not presented any evidence, not one shred, that we have a real stack overflow problem that makes it worth relying on more than the auto-save functionality and that makes it worth reaching for unsafe and completely undefined behavior. All you have is your assertion that Emacs is not safety-critical software, we can should use this technique, which you have not demonstrated saves anyone anything and which I have demonstrated is completely unsafe.