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 18128 invoked from network); 6 Jun 2023 12:43:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2023 12:43:39 -0000 Received: (qmail 25981 invoked by uid 550); 6 Jun 2023 12:43:35 -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 25944 invoked from network); 6 Jun 2023 12:43:35 -0000 Date: Tue, 6 Jun 2023 08:43:22 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230606124322.GW4163@brightrain.aerifal.cx> References: <20230606120215.49359f5c@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230606120215.49359f5c@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] printf("%lc", L'\0') 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. 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. Rich