[musl] Feature request: strftime() should set errno on failure

[musl] Feature request: strftime() should set errno on failure

[John Scott]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Hi,

My apologies, I don't have a patch, but I think strftime() should set
errno on failure as POSIX Issue 8 stipulates:
https://austingroupbugs.net/view.php?id=1386
I think this functionality is valuable enough that I'd really love it to
be implemented soon, even if it doesn't make it into the final standard
for whatever reason.

Right now, when one gets a return value of 0, there is no way to
distinguish the buffer being too small from other causes of error, which
means there's no way to tell whether a caller should try reallocating
with a larger buffer. Since strftime() is not snprintf-like (but perhaps
it could be as an extension since passing NULL to strftime is undefined,
not that I'm actually recommending that), there's no way to know how big
of a buffer is big enough. Indeed, it's not even clear if NL_TEXTMAX
applies here.

Setting errno to ERANGE would let the caller know whether a larger
buffer should be tried or if the effort will fruitlessly allocate large
amounts of memory.

Thank you.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [musl] Feature request: strftime() should set errno on failure

[Rich Felker]

On Sat, Jul 23, 2022 at 02:09:25AM +0000, John Scott wrote:
> Hi,
> 
> My apologies, I don't have a patch, but I think strftime() should set
> errno on failure as POSIX Issue 8 stipulates:
> https://austingroupbugs.net/view.php?id=1386
> I think this functionality is valuable enough that I'd really love it to
> be implemented soon, even if it doesn't make it into the final standard
> for whatever reason.
> 
> Right now, when one gets a return value of 0, there is no way to
> distinguish the buffer being too small from other causes of error, which
> means there's no way to tell whether a caller should try reallocating
> with a larger buffer. Since strftime() is not snprintf-like (but perhaps
> it could be as an extension since passing NULL to strftime is undefined,
> not that I'm actually recommending that), there's no way to know how big
> of a buffer is big enough. Indeed, it's not even clear if NL_TEXTMAX
> applies here.
> 
> Setting errno to ERANGE would let the caller know whether a larger
> buffer should be tried or if the effort will fruitlessly allocate large
> amounts of memory.

This probably isn't terribly objectionable but there should at least
be a proposal for the standard to specify setting errno if we're going
to do that. However, as specified there does not seem to be any
allowance for strftime to fail except for the "ERANGE" cause. Use of
an unrecognized conversion specifier is not an error but is undefined
behavior, so the caller cannot detect this condition; it must ensure
it doesn't happen. The return value is specified as:

    "If the total number of resulting bytes including the terminating
    null byte is not more than maxsize, these functions shall return
    the number of bytes placed into the array pointed to by s, not
    including the terminating NUL character. Otherwise, 0 shall be
    returned and the contents of the array are unspecified.

In particular this does not say 0 can be returned for any error
condition, only that 0 must be returned if the result does not fit,
and that otherwise the return value must be the number of bytes placed
in the array as a successful result. Moreover, "No errors are
defined." which forbids implementations from even defining their own
implementation-defined errors.

Rich

Re: [musl] Feature request: strftime() should set errno on failure

[John Scott]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Fri, 2022-07-22 at 22:27 -0400, Rich Felker wrote:
> In particular this does not say 0 can be returned for any error
> condition, only that 0 must be returned if the result does not fit,
> and that otherwise the return value must be the number of bytes placed
> in the array as a successful result. Moreover, "No errors are
> defined." which forbids implementations from even defining their own
> implementation-defined errors.

Thank you for bringing this to my attention, you are of course
absolutely right. In other words, as long as one provides a large enough
buffer, strftime() is required to succeed. I hereby retract my feature
request :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]