Skip to content

arch: x86: avoided increments/decrements with side effects #72372

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

Conversation

tychofrei02
Copy link
Contributor

Avoided increments/decrements with side effects.
Avoided more than one increment/decrement in for-loop.

This corresponds to following coding guideline:

A full expression containing an increment (++) or decrement (–) operator should have no other potential side effects other than that caused by the increment or decrement operator

This PR is part of the enhancement issue #48002 which port the coding guideline fixes done by BUGSENG on the https://github.com/zephyrproject-rtos/zephyr/tree/v2.7-auditable-branch back to main

The commit in this PR is a subset of the original auditable-branch commit:
671153b

@zephyrbot zephyrbot added the area: X86 x86 Architecture (32-bit) label May 6, 2024
@tychofrei02 tychofrei02 force-pushed the misra_rule_13_3_auditable_to_main_in_arch branch from 5f5791d to df92f43 Compare May 6, 2024 14:20
@andyross
Copy link
Contributor

andyross commented May 6, 2024

Can you clarify why these changes fall afoul of that rule? What side effects are being prevented here? Mostly this looks like churn just designed around removing "++" operators, which seems not in keeping with the actual rule? (And also sorta Sisyphean anyway -- you'll never get this operator out of the fingers of developers committing new code.)

@andyross
Copy link
Contributor

andyross commented May 6, 2024

Basically my read is that rule is designed to disallow code like #define STRCAT(a, b) (*(a)++ = *(b)++); which arguably is dangerous. Not to disallow routine use of ++ in loop iterators.

@tychofrei02 tychofrei02 force-pushed the misra_rule_13_3_auditable_to_main_in_arch branch from df92f43 to c51f06c Compare May 7, 2024 12:50
Copy link
Member

@jhedberg jhedberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @andyross - most changes here don't seem to have any risk of "side effects". Please provide some justification for each modification, since right now there doesn't seem to be much value in this change.

Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like there were some cases added with real rule violations, or else I missed them earlier. I flagged the specific ones that don't make sense to me.

@@ -206,7 +206,7 @@ FUNC_NORETURN void z_x86_cpu_init(struct x86_cpuboot *cpuboot)
#endif

/* Enter kernel, never return */
cpuboot->ready++;
cpuboot->ready += 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No value is used after increment here.

for (i = 0; i < VECTORS_PER_PRIORITY; ++i, ++vector) {
const int end_vector = vector + (int) VECTORS_PER_PRIORITY;

for (; vector < end_vector; ++vector) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No value is used after increment here; the comma operator doesn't inspect the value of its two subexpressions.

@@ -194,7 +195,7 @@ uintptr_t __abi efi_entry(void *img_handle, struct efi_system_table *sys_tab)
* to drain before we start banging on the same UART from the
* OS.
*/
for (volatile int i = 0; i < 50000000; i++) {
for (volatile int i = 0; i < 50000000; i += 1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No value is used after increment here.

- moved ++/-- before or after the value use

Signed-off-by: frei tycho <tfrei@baumer.com>
@tychofrei02 tychofrei02 force-pushed the misra_rule_13_3_auditable_to_main_in_arch branch from c51f06c to d23d7bc Compare May 8, 2024 08:17
@tychofrei02
Copy link
Contributor Author

Seems like there were some cases added with real rule violations, or else I missed them earlier. I flagged the specific ones that don't make sense to me.

Fair enough, I removed those changes.

@tychofrei02 tychofrei02 requested review from andyross and jhedberg May 8, 2024 10:38
@jhedberg jhedberg assigned andyross and unassigned jhedberg May 8, 2024
Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@carlescufi carlescufi merged commit 81e4b91 into zephyrproject-rtos:main May 9, 2024
@tychofrei02 tychofrei02 deleted the misra_rule_13_3_auditable_to_main_in_arch branch May 16, 2024 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: X86 x86 Architecture (32-bit)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants