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

Subject: Re: [boost] [system] A non-allocating message() overload
From: charleyb123 (charleyb123_at_[hidden])
Date: 2018-09-19 18:24:09

On Wed, Sep 19, 2018 at 11:57 AM Peter Dimov via Boost <
boost_at_[hidden]> wrote:

> One of the objections against <system_error> is that message() needs to
> allocate memory, because it returns an std::string. This is true even for
> user-defined categories that can implement it without allocating, with a
> static message table.
>
> 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"

Question:  Is there a *guarantee* that 'message()' never return 'nullptr'?
(Is that ever desired?)

--charley