Stack overflow gets a mention in this article: http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences:)
-- Ziad On Tue, Oct 29, 2013 at 1:24 PM, Daniel Micay <[email protected]> wrote: > On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis <[email protected]> wrote: > >> If I understand correctly, what you are proposing is to offer fixed >> size stacks and to use a guard page to check for stack overflow (vs a >> stack preamble)? >> >> My two thoughts are: >> >> 1. I do think segmented stacks offer several tangible benefits: >> >> - Recursion limited only by available memory / address space >> - Avoid chewing up address space on 32 bit builds >> >> However, I can accept that on balance they are not worth the price, >> given that point #2 is probably not that important for 64-bit systems. >> >> It is sad to lose limitless recursion but typically one can rewrite >> routines that recurse arbitrarily deep to use a stack on the heap, >> though sometimes the code is very unnatural, and using a stack on the >> heap will not play as well with lifetimes, since the compiler doesn't >> know that you are obeying a stack discipline. >> >> 2. I think that our official semantics for stack overflow should be >> task failure, not abort. There are some technical challenges to be >> overcome with regard to the best way to signal/detect stack overflow, >> and I'm fine with this being a "todo" item (possibly for a long time). >> But abort is wrong. >> >> One non-technical difficulty to failing on overflow is how to handle >> user-defined destructors when there is no stack to run them on -- but >> I think this is adequately addressed by keeping a red zone (so that >> simple dtors work) and implementing Graydon's plan for handling >> recursive failure otherwise. We also have to modify drop glue to not >> be recursive (see point #1 about the convenience of limitless >> recursion -- though of course drop glue must be ready for OOM as >> well). >> > > If we want to unwind on task failure, we'll need to disable the `prune-eh` > pass that bubbles up `nounwind` since every function will be able to > unwind. I think it will cause a very significant increase in code size. > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
