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 something like truncation or returning "Insufficient buffer size for message" would 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 probably uncommon). 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: https://stackoverflow.com/questions/37662614/calling-vkenumeratedeviceextens... ...or more simply: int count = 0; vkGetSwapchainImagesKHR(device, swapchain, &count, nullptr); // (e.g.) return count = 3. VkImage images[3]; vkGetSwapchainImagesKHR(device, swapchain, &count, images); // (e.g.) return ID = 4,5,6 --charley