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.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22441 invoked from network); 25 Jun 2023 15:25:04 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2023 15:25:04 -0000 Received: (qmail 28479 invoked by uid 550); 25 Jun 2023 15:24:59 -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 28430 invoked from network); 25 Jun 2023 15:24:57 -0000 Date: Sun, 25 Jun 2023 11:24:44 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230625152443.GQ4163@brightrain.aerifal.cx> References: <20230625094818.5e6b156c@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230625094818.5e6b156c@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] C23: other last minute changes On Sun, Jun 25, 2023 at 09:48:18AM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Hello, > there were other last minute (in the literal sense of the term) > changes to C23 that might impact musl. I updated the summary page at > > https://gustedt.gitlabpages.inria.fr/c23-library/ > > As far as I can see these are > > - `PRI` macros for narrow types now have to be exact, musl does not > seem to conform to this new requirement Yes; this probably requires some minor conditional logic for the FAST cases but otherwise it should be very straightforward to change. It's not clear to me what the conformance distinction is here, though. Is it not undefined behavior to pass an argument for %hhd (for example) whose value is not in the range of a signed char? Perhaps values in the range of unsigned char are also supposed to be okay, but should get interpreted as signed? I don't see where printf is specified to handle arbitrary wrong-type-but-rank-<=-int values, though..? > - the `lc` specifier for `printf` does print NUL for a nul > character, we already talked about this > > For the first, a change is conforming to C17 so it can be done > immediately without problems. The second is in principle a normative > change in C and in POSIX, but it seems that all other POSIX > implementations already are doing this, so probably we should just > fall in line. Yes, this change can be made immediately. Since actually adding single-wchar processing code seems like messy duplication of the code already in the %ls case, my leaning would be just adding this as (pseudocode since a new label is needed too): case 'C' + if (!arg.i) goto case 'c'; wc[0] = arg.i; > There are also > > - `mktime` and `timegm` are not supposed to change `tm_wday` if the > conversion fails My default interpretation (which admittedly we don't *always* follow, and is difficult or impossible in a few cases) is that, if a function is specified to modify some pointed-to object on successful completion, that it's not even allowed to modify it on failure. And indeed we do not touch *tm until the final success path in mktime/timegm. > - `fputwc` now also sets the error indicator of the stream if an > encoding error occurs. This was previously already required by > POSIX. > > I don't think that musl has problems here That sounds right. I guess fputwc is still unfixed, though? I probably should have followed up on that from the Austin Group side.. Rich