Is nlr_jump_fail absolutely necessary?

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
cduran
Posts: 67
Joined: Thu Mar 17, 2016 4:52 pm

Is nlr_jump_fail absolutely necessary?

Post by cduran » Mon Mar 23, 2020 8:57 pm

I'm getting a compiler warning on the definition of nlr_jump_fail(). We try to keep our code as clean as possible and I want to remove this warning. I know an easy fix would be to add an exit(0) to the function, but I'd really rather not. I searched the project and found that it was only called within the MP_NLR_JUMP_HEAD macro, and this macro isn't called anywhere is in our port. Would it hurt anything to just remove the MP_NLR_JUMP_HEAD and nlr_jump_fail() all together?

User avatar
jimmo
Posts: 1685
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Is nlr_jump_fail absolutely necessary?

Post by jimmo » Tue Mar 24, 2020 12:44 am

I'm not quite sure I understand your question. nlr_jump_fail is provided by the port. What's the warning you're seeing?

If your port doesn't use NLR (it uses setjmp instead?) then you don't need to provide it in your port.

cduran
Posts: 67
Joined: Thu Mar 17, 2016 4:52 pm

Re: Is nlr_jump_fail absolutely necessary?

Post by cduran » Tue Mar 24, 2020 1:30 pm

jimmo wrote:
Tue Mar 24, 2020 12:44 am
I'm not quite sure I understand your question. nlr_jump_fail is provided by the port. What's the warning you're seeing?

If your port doesn't use NLR (it uses setjmp instead?) then you don't need to provide it in your port.
The warning is "noreturn function does return".

I misunderstood what was happening, I found that either an infinite loop or and exit will silence the warning. However neither of those are an option for our firmware. We can't have the rest of the firmware crash or hang there. Can we put code to "reboot" mp in case of that failure?

User avatar
jimmo
Posts: 1685
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Is nlr_jump_fail absolutely necessary?

Post by jimmo » Wed Mar 25, 2020 3:47 am

The situation where this happens is pretty dire -- i.e. the NLR stack underflowed. Who knows what state things are in... there's kind of nothing to return _to_.

(This is not like the program didn't catch an Python-level exception, it's that there's a serious bug in the MicroPython firmware or native emitter).

Post Reply