[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220723022720.GD7074@brightrain.aerifal.cx>
Date: Fri, 22 Jul 2022 22:27:20 -0400
From: Rich Felker <dalias@...c.org>
To: John Scott <jscott@...teo.net>
Cc: musl@...ts.openwall.com
Subject: Re: Feature request: strftime() should set errno on failure
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
