Refactor the current C/C++ compiler warning sets to establish a consistent warning policy aligned with MISRA-oriented development.

[nradakovic]

Summary

The current warning configuration should be reviewed and restructured to provide a clear, maintainable, and consistent set of compiler warnings across supported C/C++ compilers and platforms. The new warning sets should prioritize diagnostics that help identify issues addressed by the MISRA C/C++ guidelines while avoiding compiler-specific inconsistencies and unnecessary noise.

This work focuses on compiler diagnostics and warning policy. Enabling compiler warnings alone does not constitute MISRA compliance; MISRA-specific static analysis and project-level compliance activities remain separate concerns.

Goal

Establish a standardized C/C++ compiler warning policy that provides a strong foundation for MISRA-oriented development and can be consistently applied across S-CORE projects and supported toolchains.

The resulting warning sets should be structured, documented, and maintainable, with clear handling of compiler-specific capabilities and differences.

Scope

The refactoring should cover:
TBD

Proposed Deliverables

• Refactored and standardized C/C++ compiler warning sets
• Warning sets aligned with relevant MISRA C/C++ guidelines where compiler diagnostics provide applicable coverage
• Clearly defined warning levels and policy categories
• Consistent warning configuration across supported compilers
• Explicit handling of compiler-specific warnings and unsupported diagnostics
• Identification and documentation of warnings that cannot be enforced consistently across all platforms
• Validation of the new warning sets against representative S-CORE C/C++ targets
• Updated documentation describing the warning policy and its intended use
• Release notes documenting the changes and any migration considerations

Validation Expectations

Before closing this issue, verify:

• The new warning sets can be applied successfully to supported C/C++ targets
• Relevant compiler diagnostics associated with MISRA-oriented rules are enabled where supported
• Warning configurations behave consistently across supported compiler/toolchain versions
• No unintended changes to compilation or linking behavior are introduced
• Existing projects can migrate to the new warning sets without unexpected build failures beyond newly enforced diagnostics
• Compiler-specific warnings are correctly guarded or isolated where required
• Representative S-CORE projects build successfully using the new warning policy
• Known gaps between compiler warnings and MISRA requirements are explicitly documented

Acceptance Criteria

• A clearly defined and documented C/C++ warning policy is available
• Warning sets are refactored into a maintainable structure suitable for reuse across S-CORE projects
• Relevant MISRA-oriented compiler diagnostics are enabled where technically applicable
• Compiler- and platform-specific differences are handled explicitly
• Representative C/C++ targets are validated with the new warning sets
• Newly introduced warnings and required source-code changes are identified and documented
• The documentation clearly states that compiler warning configuration alone does not provide MISRA compliance
• Known limitations and MISRA rules requiring dedicated static analysis are documented

Checklist

• Inventory the current C/C++ warning sets
• Identify duplicated, redundant, obsolete, or inconsistent warning options
• Map applicable compiler warnings to relevant MISRA C/C++ guidelines
• Define the target warning policy and categories
• Define required, recommended, and optional warnings
• Define handling for compiler-specific warnings
• Refactor warning configuration and Bazel integration
• Validate GCC warning behavior across supported GCC versions
• Validate warning behavior for supported non-GCC/vendor toolchains
• Build representative S-CORE C/C++ targets with the new warning sets
• Analyze newly reported warnings and required source-code changes
• Document warnings that cannot be consistently enforced
• Document MISRA rules requiring dedicated static analysis
• Update README/docs with the new warning policy
• Prepare release notes and migration guidance