Re: [boost] [system] A non-allocating message() overload

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.