From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19700 invoked from network); 23 Jul 2022 02:27:37 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 23 Jul 2022 02:27:37 -0000 Received: (qmail 26366 invoked by uid 550); 23 Jul 2022 02:27:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26328 invoked from network); 23 Jul 2022 02:27:33 -0000 Date: Fri, 22 Jul 2022 22:27:20 -0400 From: Rich Felker To: John Scott Cc: musl@lists.openwall.com Message-ID: <20220723022720.GD7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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