The rationale of the rule says:
> Also, some string handling functions only report errors through the use of errno
But that't not the case for std:: strerror, it does not report any errors through errno, nor is it possible for it to "read beyond the bounds of an object passed as a parameter", so it's perfectly safe to use it.
An alternative is to use std::make_error_condition(static_cast<std::errc>(errno)).message(), but it seems like overkill just to achieve the same thing, making the code far less readable.
It's also worth noting that MISRA does not ban the usage of errno (besides the restriction from 22.4.1), which is required for using POSIX functions that don't have any equivalent in the Standard Library.
Would you agree?
> Also, some string handling functions only report errors through the use of errno
But that't not the case for std:: strerror, it does not report any errors through errno, nor is it possible for it to "read beyond the bounds of an object passed as a parameter", so it's perfectly safe to use it.
An alternative is to use std::make_error_condition(static_cast<std::errc>(errno)).message(), but it seems like overkill just to achieve the same thing, making the code far less readable.
It's also worth noting that MISRA does not ban the usage of errno (besides the restriction from 22.4.1), which is required for using POSIX functions that don't have any equivalent in the Standard Library.
Would you agree?