Subject: Re: [boost] [system] A non-allocating message() overload
From: Peter Dimov (lists_at_[hidden])
Date: 2018-09-19 19:47:06
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk