Subject: Re: [boost] [system] A non-allocating message() overload
From: Peter Dimov (lists_at_[hidden])
Date: 2018-09-19 19:47:06
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.