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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7564 invoked from network); 24 Jun 2023 17:25:11 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2023 17:25:11 -0000 Received: (qmail 13831 invoked by uid 550); 24 Jun 2023 17:25:08 -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 13790 invoked from network); 24 Jun 2023 17:25:07 -0000 Date: Sat, 24 Jun 2023 13:24:55 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230624172454.GP4163@brightrain.aerifal.cx> References: <20230606120215.49359f5c@inria.fr> <20230606124322.GW4163@brightrain.aerifal.cx> <20230624152155.2e011149@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230624152155.2e011149@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] printf("%lc", L'\0') On Sat, Jun 24, 2023 at 03:21:55PM +0200, Jₑₙₛ Gustedt wrote: > Rich, > > on Tue, 6 Jun 2023 08:43:22 -0400 you (Rich Felker ) > wrote: > > > On Tue, Jun 06, 2023 at 12:02:15PM +0200, Jₑₙₛ Gustedt wrote: > > > Hello, > > > the Austin Group has a bug at > > > > > > https://austingroupbugs.net/view.php?id=1647 > > > > > > that lead to a (quite late) ballot comment for C23. It seems that > > > musl is the only implementation here that plays by the book and has > > > no byte of output at all for this call > > > > > > printf("%lc", L'\0'); > > > > > > All others seem to be more consistent with the other "c" output > > > formats and print one NUL byte. > > > > > > Are there any feelings if we are going to change this in the sense > > > as AG proposes? > > > > Provided the change is to be aligned between POSIX and ISO C, and that > > all existing historical implementations except musl do the thing > > that's proposed, I don't think I have any objection to the change. > > It's a little more work and less elegant on the implementation side. > > In this week's last round of ballot resolution WG14 chose option 1, so > this change. > > > Is it really confirmed that all historical C implementations, not just > > all historical POSIX ones, differ from the specification in this way? > > That seems rather surprising (and amusing that nobody else bothered to > > read the spec when implementing). It would be nice to make sure > > they're informed and in agreement on this, if there are any others. > > There was only time to check this for implementation that were there > (in particular IBM) but WG14 chose to do this regardless of this lack of > information. OK, so to be clear, WG14 is making the change proposed in https://austingroupbugs.net/view.php?id=1647 and changing the standard to specify that printf("%lc", L'\0') should produce 1 NUL character? Rich