Skip to content

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 27, 2025

Conversation

Avamander
Copy link
Contributor

Summary

This PR annotates _Error_Handler with __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 getAssociatedChannel in HardwareTimer.cpp might* underflow when 1 is 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 no Error_Handler defined 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

HardwareTimer and 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_Handler even if NDEBUG is enabled (and a replacement is not defined). I lack sufficient experience with the core to know if this would be safer everything considered.

@fpistm
Copy link
Member

fpistm commented May 26, 2025

Thanks for the PR, it makes sense.

HardwareTimer and 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.
If the value is not correct it fails in the error handler (infinite loop). Returning a safe value is not easy as we do not know which timer is used nor if something is connected to it.

An another question is if there should there be a default halt loop Error_Handler even if NDEBUG is enabled (and a replacement is not defined). I lack sufficient experience with the core to know if this would be safer everything considered.

If NDEBUG and not redefined, a default halt loop is defined (infiinite loop). So don't see what else we can do.

@fpistm fpistm added the enhancement New feature or request label May 26, 2025
@fpistm fpistm added this to the 2.11.0 milestone May 26, 2025
@github-project-automation github-project-automation bot moved this from In progress to Reviewer approved in STM32 core based on ST HAL May 26, 2025
@fpistm fpistm merged commit 9e0d259 into stm32duino:main May 27, 2025
24 checks passed
@github-project-automation github-project-automation bot moved this from Reviewer approved to Done in STM32 core based on ST HAL May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

Successfully merging this pull request may close these issues.

2 participants