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 12043 invoked from network); 12 Jun 2023 23:54:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 12 Jun 2023 23:54:56 -0000 Received: (qmail 17546 invoked by uid 550); 12 Jun 2023 23:54:53 -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 17514 invoked from network); 12 Jun 2023 23:54:53 -0000 Date: Mon, 12 Jun 2023 19:54:38 -0400 From: Rich Felker To: Bruno Haible Cc: musl@lists.openwall.com Message-ID: <20230612235437.GF4163@brightrain.aerifal.cx> References: <16376867.hlxOUv9cDv@nimes> <20230612210159.GC4163@brightrain.aerifal.cx> <20230612211336.GD4163@brightrain.aerifal.cx> <2776403.6YUMPnJmAY@nimes> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2776403.6YUMPnJmAY@nimes> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] swprintf cannot handle the character 0xff On Tue, Jun 13, 2023 at 01:09:26AM +0200, Bruno Haible wrote: > Rich Felker wrote: > > However, for wide printf: > > > > c > > If no l (ell) qualifier is present, the int argument shall be > > converted to a wide character as if by calling the btowc() > > function and the resulting wide character shall be written. > > > > There's no specification of what happens if btowc fails here, but > > passing EOF to btowc is required to fail and return WEOF. > > Possibly. But in the test program that I provided, I pass 255, not > -1 (= EOF). Right. I'm not questioning that your bug report is correct, just my initial proposal for fixing it. Since wide printf is supposed to perform the conversion as if by btowc, it should presumably handle -1 (as opposed to 255) as an error path. > It's well-known that the preferred way to convert a 'char' to 'int' > is not by direct assigment/cast, but by casting to 'unsigned char'. > That's well-known from [f]getc(), the functions, etc. > You don't need to particularly care about programmers who pass > '\xff' to a function that expects an 'int'. On targets where plain char is signed, '\xff' has value -1, meaning it would work for %c with narrow printf but not with wide printf. I wonder if this should actually be a defect and if wide printf should be specified as converting the value, converted to (unsigned char), as if by btowc, rather than the raw value. Rich