[SimonSapin]

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]

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

[zokier]

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

You'd have to implement your own stack unwinding in a bare metal context, if you wanted it at all, yeah.

[SimonSapin]

Is it important, when there is no other thread or process that could use any resource you're holding?

[zokier]

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

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

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

[zokier]

Rust notably has slightly weakened RAII semantics: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe...

tldr is that Rust does not guarantee that dtors are run

[jdub]

Now that's a cute panic_fmt. :-)