6 ms·
I now have a "more real" panic_fmt in the repository: #[lang = "panic_fmt"] extern fn panic_fmt(details: ::core::fmt::Arguments, file: &'static str, li
by SimonSapin 10y ago
I now have a "more real" panic_fmt in the repository:
#[lang = "panic_fmt"]
extern fn panic_fmt(details: ::core::fmt::Arguments, file: &'static str, line: u32) -> ! {
println!("Panic at {}:{}, {}", file, line, details);
let row_2 = ::gpio::Pin::output(::pins::ROW_2);
let col_3 = ::gpio::Pin::output(::pins::COL_3);
row_2.set_high();
loop {
col_3.set_low();
::busy_loop::wait_approx_ms(5);
col_3.set_high();
::busy_loop::wait_approx_ms(200);
}
}
Note that println! is a macro I defined myself, it writes to the serial port.
I still don’t know about eh_personality, though.
- jdub 10y agoNow that's a cute panic_fmt. :-)
- jdub 10y agowrt eh_personality, there's a good short answer with a link to a good (very!) long answer here: http://stackoverflow.com/questions/16597350/what-is-an-exception-handling-personality-function http://stackoverflow.com/questions/16597350/what-is-an-excep...
- zokier 10y agoSo basically if I got it right, non-terminating panic_fmt and empty eh_personality means that we don't get stack unwinding at all, which also means that destructors don't get called. That could be fairly important for RAII heavy code.
- jdub 10y agoYou'd have to implement your own stack unwinding in a bare metal context, if you wanted it at all, yeah.
- SimonSapin 10y agoIs it important, when there is no other thread or process that could use any resource you're holding?
- zokier 10y agoResource wouldn't necessary be something internal in the application, it could be also some external system or something like that. You might want to close TCP connections cleanly in destructors, or maybe more relevantly for embedded systems the resource might be some actual physical gadget that is activated/deactivated. Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design.
- monocasa 10y ago> Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design. Eh, I'd only argue that in the case of garbage collected languages. In RAII languages like Rust and C++, it's the preferred way.
- twic 10y agoThere's a classic interview question about RAII along the lines of "in what situation can a RAII resource be acquired, but not released?". The key answer is "if someone turns the power off". panic_fmt entering an infinite loop leads to pretty similar results as someone turning the power off. The stack will not be unwound, destructors will not be run, and bad designs will leave external resources in an inconsistent state.
- monocasa 10y agoI mean, sure. loop {} ^--- That'll also cause destructors to not be run.
- zokier 10y agoRust notably has slightly weakened RAII semantics: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md https://github.com/rust-lang/rfcs/blob/master/text/1066-safe... tldr is that Rust does not guarantee that dtors are run