- Notifications
You must be signed in to change notification settings - Fork1k
Annotate Error_Handler with noreturn to help analysis#2739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Signed-off-by: Avamander <avamander@gmail.com>
fpistm commentedMay 26, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Thanks for the PR, it makes sense.
If NDEBUG and not redefined, a default halt loop is defined (infiinite loop). So don't see what else we can do. |
9e0d259 intostm32duino:mainUh oh!
There was an error while loading.Please reload this page.
Summary
This PR annotates
_Error_Handlerwith__attribute__((noreturn))that informs the compiler that the given function does not return.Motivation
This simplifies analysis for both the compiler and external tools.
For example it fixes a warning I got, that the result of
getAssociatedChannelinHardwareTimer.cppmight* underflow when1is subtracted from the default return value of zero and this would then result in an out of bounds array access. "Might" in this context probably means to the compiler that there's either noError_Handlerdefined or there's one that returns. In any case, the fact that these errors can pop up (like they did for me), means the code flow is not always clear enough for the compiler.Additional notes
HardwareTimerand other similar files could maybe be updated in a way to fail/return safe values in all cases? Though this might cause undesirable seemingly working "default" behaviour while a crash would be very visible.An another question is if there should there be a default halt loop
Error_Handlereven ifNDEBUGis enabled (and a replacement is not defined). I lack sufficient experience with the core to know if this would be safer everything considered.