Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
fpistm merged 1 commit intostm32duino:mainfromAvamander:patch-1
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 ofgetAssociatedChannel inHardwareTimer.cppmight* underflow when1 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 noError_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 loopError_Handler even ifNDEBUG is enabled (and a replacement is not defined). I lack sufficient experience with the core to know if this would be safer everything considered.

Signed-off-by: Avamander <avamander@gmail.com>
@fpistm
Copy link
Member

fpistm commentedMay 26, 2025
edited
Loading

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 loopError_Handler even ifNDEBUG 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.

Avamander reacted with thumbs up emoji

@fpistmfpistm added the enhancementNew feature or request labelMay 26, 2025
@fpistmfpistm added this to the2.11.0 milestoneMay 26, 2025
@github-project-automationgithub-project-automationbot moved this fromIn progress toReviewer approved inSTM32 core based on ST HALMay 26, 2025
@fpistmfpistm merged commit9e0d259 intostm32duino:mainMay 27, 2025
24 checks passed
@github-project-automationgithub-project-automationbot moved this fromReviewer approved toDone inSTM32 core based on ST HALMay 27, 2025
@AvamanderAvamander deleted the patch-1 branchJune 1, 2025 11:20
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fpistmfpistmfpistm approved these changes

Assignees

No one assigned

Labels

enhancementNew feature or request

Projects

Milestone

2.11.0

Development

Successfully merging this pull request may close these issues.

2 participants

@Avamander@fpistm

[8]ページ先頭

©2009-2025 Movatter.jp