MISRA Discussion Forums
Rule 8.2.8 - why aren't aliases allowed? - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: MISRA C++:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=188)
+---- Forum: 4.8 Expressions (https://forum.misra.org.uk/forumdisplay.php?fid=194)
+---- Thread: Rule 8.2.8 - why aren't aliases allowed? (/showthread.php?tid=1732)



Rule 8.2.8 - why aren't aliases allowed? - cgpzs - 18-03-2025

The rule provides this example as Non-Compliant:

Code:
    using hashPtr_t = std::uintptr_t;
    auto p2 = reinterpret_cast< hashPtr_t >( s );  // Non-compliant

However, there's nowhere in the Rule Text, Rationale or Amplification that explains why aliases are not allowed. Can you clarify?

Aliases are good for removing code duplication and ensuring the correct type is used in all contexts where it's needed; having to remove the alias and spell std::uintptr_t everywhere hurts code readability and maintainability, without any clear benefit.

Static analyzers can easily detect the usage of std::uintptr_t even if it's behind an alias.


RE: Rule 8.2.8 - why aren't aliases allowed? - misra cpp - 28-03-2025

The aim of the rule is to make the intent of the cast clear.

If aliases were allowed, as std::uintptr_t is itself an alias to some other type T, this would mean that any cast to T (or other alias of T) would also have to be allowed. You have lost the clarity that you are intentionally casting a pointer to a 'big enough' integer.