charleyb123 wrote: ...
To address this, I'm thinking of adding the following overload to boost::system::error_category (with the intent of proposing it for std::error_category):
virtual char const* message( int ev, char* buffer, size_t len ) noexcept;
This is modeled after the glibc-specific version of strerror_r (and in fact has the exact same signature and behavior). If the implementation has a static character literal corresponding to `ev`, it returns it directly. If not, it composes an error message into the provided buffer, then returns `buffer`.
Comments?
I *really* like this interface (pass in buffer-to-be-populated, or return internal static buffer).
Am I correct in assuming the user could then:
... ec = ...; char* my_buf = ...; size_t my_buf_size = ...; char const* msg = ec.message(SOME_ERR_ENUM, my_buf, my_buf_size); if(msg != my_buf) { // ...delete "my_buf", it is not needed }
// TRUST that "msg" is still valid (must reference static-internal-buffer, or is "my_buf"
Yes, this would be guaranteed.
Question: Is there a *guarantee* that 'message()' never return 'nullptr'? (Is that ever desired?)
The only failure mode would be when the function needs to compose a message and the provided buffer is too small to hold it; I'll have to check what strerror_r(12345, buffer, 1) (for instance) does but in my opinion nullptr should not be a valid return value; in this case something like truncation or returning "Insufficient buffer size for message" would be my preference.