Open avolkov-1221 opened 1 month ago
Why not just name the bitfields? Unnamed bitfields may be valid, but they are quite confusing IMHO.
If you'll have only one such field. If have tenth of them, then _r1..r1XX will not add readability. In any case it's 'false positive'.
Btw I've found that this code is passed:
struct {
unsigned int a:3;
unsigned int :3; /* reserved unnamed field */
unsigned int b:3;
};
So, the problem is that the script treats uint32_t not as a type, but as a variable.
It would appear that unnamed bitfields are not disallowed by MISRA.
Length of a named signed bit-field is less than 2
They are definitely useful when defining in-memory structures, so I would support this bug being fixed in checkpatch.
It would appear that unnamed bitfields are not disallowed by MISRA.
Length of a named signed bit-field is less than 2
They are definitely useful when defining in-memory structures, so I would support this bug being fixed in checkpatch.
Btw I checked the latest version of the script on kernel.org, its behaviour is the same. So we should probably forward the bug report to them too.
Describe the bug
The current scripts/checkpatch.pl script give a false positive spacing error for the following, valid and correct, declaration:
And then checkpatch.pl will fail the check with error:
To Reproduce
Just try to check the attached patch.
Expected behavior
The check should be passed without any errors.
Impact
This bug will block committing any C source file with empty bitfields necessary for the most of the peripherals hardware registers declarations.
Logs and console output
Environment (please complete the following information):
Additional context