21.2.2 Why shall std::strerror not be used?

[cgpzs]

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?

[misra cpp]

Firstly, the prohibition on std:: strerror was intentional.  std:: strerror may not use errno, but can still lead to undefined behaviour.

It was not intended that the rational should be taken an an exhaustive description of issues with all 37 string functions in these headers, rather than an overview.

We could make the rationale more vague, which probably wouldn't help anyone, or make it specify the issues with each of the 37 functions individually. This would make the rationale much much larger for little practical benefit.

[cgpzs]

Firstly, the prohibition on std:: strerror was intentional.  std:: strerror may not use errno, but can still lead to undefined behaviour.

It was not intended that the rational should be taken an an exhaustive description of issues with all 37 string functions in these headers, rather than an overview.

We could make the rationale more vague, which probably wouldn't help anyone, or make it specify the issues with each of the 37 functions individually. This would make the rationale much much larger for little practical benefit.

Thanks for the clarification! I don't think it's necessary to have a description of all 37 functions, since most of them suffer from the same problems. But std:: strerror is entirely different, it just so happens to be in the same header file as others. I think it would have fit better into a separate rule, possibly next to 22.4.1. This would allow for elaborating on the specific issues of std:: strerror. 

For example, it's unclear if ":: strerror_r" would be an acceptable replacement for std:: strerror, or if also that would be banned by MISRA.

[misra cpp]

strerror_r is not part of the C++ standard library, so isn't covered by the MISRA rules (other than the requirement to validate third-party libraries).

You can always raise a deviation to allow the use of std::error, but be aware of 25.5.2 and 25.5.3  ('must be used as if the return type is a pointer to const-qualified type'  and  'the value returned must not be used following a subsequent call to the same function')