From: Rich Felker <dalias@libc.org>
To: John Scott <jscott@posteo.net>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Feature request: strftime() should set errno on failure
Date: Fri, 22 Jul 2022 22:27:20 -0400 [thread overview]
Message-ID: <20220723022720.GD7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <ffcc449898d944f3409b329ccdca4fc7d2664654.camel@posteo.net>
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
next prev parent reply other threads:[~2022-07-23 2:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-23 2:09 John Scott
2022-07-23 2:27 ` Rich Felker [this message]
2022-07-23 2:42 ` John Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220723022720.GD7074@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=jscott@posteo.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).