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 22216 invoked from network); 6 Jun 2023 14:19:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2023 14:19:35 -0000 Received: (qmail 3231 invoked by uid 550); 6 Jun 2023 14:19:32 -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 3197 invoked from network); 6 Jun 2023 14:19:32 -0000 Date: Tue, 6 Jun 2023 10:19:19 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230606141919.GX4163@brightrain.aerifal.cx> References: <20230606120215.49359f5c@inria.fr> <20230606124322.GW4163@brightrain.aerifal.cx> <20230606160708.3aab4a26@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230606160708.3aab4a26@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] printf("%lc", L'\0') On Tue, Jun 06, 2023 at 04:07:08PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Tue, 6 Jun 2023 08:43:22 -0400 you (Rich Felker ) > wrote: > > > Is it really confirmed that all historical C implementations, not just > > all historical POSIX ones, differ from the specification in this way? > > I personnally don't know much more than I posted in my question. AG > tells us that musl is the only one they know about > > we are only aware of one (musl) that obeys a strict reading of > the C standard. > > I don't know about historic implementations evidently. The class AG is considering is likely POSIX/POSIXy implementations, not all C implementations. > > It would be nice to make sure they're informed and in agreement on > > this, if there are any others. > > That will be one of the difficulties with a request that comes in so > late in the procedure. We will have not much data to base our > decision, but for the projects where the WG14 members are implicated > in one way or another. In that case I would probably lean towards asking AG to instead make a change to (CX shaded) "it is unspecified whether a single zero byte is written or the conversion has no output" and not imposing a change on potentially unaware C implementations that have nothing to do with POSIX, nor imposing a requirement to conflict with ISO C. I really doubt there is anyone who cares about the specific behavior in this case, but it seems unprofessional to do something like this last-minute. "Future directions" notes could be added that this might change. Rich