Subject: Re: [boost] [system] A non-allocating message() overload
From: charleyb123 (charleyb123_at_[hidden])
Date: 2018-09-20 12:10:44
> > charleyb123 wrote:
> > > 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
> > like truncation or returning "Insufficient buffer size for message"
> > be my preference.
Peter Dimov respondeth:
> On reflection, I take that back. nullptr will be a valid return value, but
> only in the case where you pass nullptr as the buffer (and, accordingly, 0
> as the length.)
> That is, the function should not "fail" with "Insufficient buffer size for
> message", it will just fill the buffer and truncate, even when the buffer
> size is something ridiculously small such as 2, 1, or even 0.
> This enables the (apparently idiomatic when using strerror_r) technique of
> using `message( ev, nullptr, 0 )` to detect whether the message is static,
> and do something else if it isn't.
Ah, that had not occurred to me. Ok, yes, that could be useful (although
I previously could think of no use for returning 'nullptr', but I accept
this as the (possibly only) scenario where that might be useful.
Not to wander, but does this then suggest there might be interest in the
two-call idiom to detect the buffer-size *required*, so the caller can
allocate? (This has become increasingly popular such as in the Vulkan
APIs, and Microsoft create-process/console functions), for example see:
...or more simply:
int count = 0;
vkGetSwapchainImagesKHR(device, swapchain, &count, nullptr); // (e.g.)
return count = 3.
vkGetSwapchainImagesKHR(device, swapchain, &count, images); // (e.g.)
return ID = 4,5,6