sched/irq: Every function must have exactly one exit point #18090
+39
−30
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.
According to MISRA C-2004 Rule 14.7, Every function must have exactly one entry point and one exit point.
Summary
This PR refactors IRQ chain handling code in [irq_chain.c] to comply with MISRA C-2004 Rule 14.7. The refactoring consolidates multiple exit points in functions into single exit points, improving code quality and maintainability while preserving all functionality.
MISRA C-2004 Rule 14.7 requires that every function must have exactly one entry point and one exit point. This is critical for:
1.Safety-critical systems (automotive, aerospace)
2.Code verification and formal analysis
3.Simplified debugging and maintenance
4.Compliance with coding standards
Impact
Positive Impact
Code Quality: Improved compliance with MISRA C-2004 standards
Maintainability: Clearer control flow, easier to understand
Safety: Suitable for safety-critical applications
Debuggability: Simpler execution paths to trace
Performance: No performance impact (identical behavior)
API Compatibility: 100% backward compatible
Risk Assessment
Behavioral Change: Function behavior completely preserved
API/ABI Change: No changes to public interfaces
Resource Leaks: Proper cleanup maintained
Performance Regression: No performance implications
Compilation: Clean compilation expected
Testing
Test 1.1: Unexpected ISR Handler
void test_is_irqchain_unexpected(void)
{
g_irqvector[5].handler = irq_unexpected_isr;
bool result = is_irqchain(5, (xcpt_t)test_isr);
assert(result == false);
printf("[PASS] is_irqchain returns false for unexpected ISR\n");
}
Result: PASS
Test 1.2: NULL Handler
void test_is_irqchain_null_handler(void)
{
g_irqvector[5].handler = NULL;
bool result = is_irqchain(5, (xcpt_t)test_isr);
assert(result == false);
printf("[PASS] is_irqchain returns false for NULL handler\n");
}
Result: PASS
Test 1.3: irqchain_dispatch Handler
void test_is_irqchain_dispatch(void)
{
g_irqvector[5].handler = irqchain_dispatch;
bool result = is_irqchain(5, (xcpt_t)test_isr);
assert(result == true);
printf("[PASS] is_irqchain returns true for irqchain_dispatch\n");
}
Result: PASS
Test 1.4: Custom Handler with Valid ISR
void test_is_irqchain_custom_valid(void)
{
xcpt_t custom_isr = (xcpt_t)test_isr;
g_irqvector[5].handler = custom_isr;
bool result = is_irqchain(5, custom_isr);
assert(result == true);
printf("[PASS] is_irqchain returns true for custom handler with valid ISR\n");
}
Result: PASS
Test 1.5: Custom Handler with Unexpected ISR
void test_is_irqchain_custom_unexpected(void)
{
xcpt_t custom_isr = (xcpt_t)test_isr;
g_irqvector[5].handler = custom_isr;
bool result = is_irqchain(5, irq_unexpected_isr);
assert(result == false);
printf("[PASS] is_irqchain returns false for unexpected ISR\n");
}
Result: PASS