Fix #14150 (Add unionzeroinit check)#7870
Merged
danmar merged 1 commit intodanmar:mainfrom Oct 12, 2025
Merged
Conversation
Contributor
Author
|
Second attempt of #7843 which accidently got merged. |
danmar
reviewed
Oct 8, 2025
Owner
danmar
left a comment
danmar
left a comment
There was a problem hiding this comment.
Thank you for working on this. I think it looks good overall but have some nits.
Please write a little description in the CheckOther::classInfo() method.
please add a line in the releasenotes.txt
Contributor
Author
|
I hope all feedback have been addressed at this point. |
This has bitten me before and is definitely a foot gun. GCC 15[1] changed their
semantics related to zero initialization of unions; from initializing the
complete union (sizeof union) to only zero initializing the first member. If the
same first member is not the largest one, the state of the remaining storage is
considered undefined and in practice most likely stack garbage.
The unionzeroinit checker can detect such scenarios and emit a warning. It does
not cover the designated initializers as I would interpret those as being
intentional.
Example output from one of my projects:
```
x86-decoder.c:294:7: warning: Zero initializing union Evex does not guarantee its complete storage to be zero initialized as its largest member is not declared as the first member. Consider making u32 the first member or favor memset(). [unionzeroinit-unionzeroinit]
Evex evex = {0};
^
```
[1] https://trofi.github.io/posts/328-c-union-init-and-gcc-15.html
|
danmar
approved these changes
Oct 12, 2025
Owner
|
@mptre thanks.. now I merged it by intention :-) please close the ticket. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This has bitten me before and is definitely a foot gun. GCC 15[1] changed their semantics related to zero initialization of unions; from initializing the complete union (sizeof union) to only zero initializing the first member. If the same first member is not the largest one, the state of the remaining storage is considered undefined and in practice most likely stack garbage.
The unionzeroinit checker can detect such scenarios and emit a warning. It does not cover the designated initializers as I would interpret those as being intentional.
Example output from one of my projects:
[1] https://trofi.github.io/posts/328-c-union-init-and-gcc-15.html