From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id CA1673858416 for ; Wed, 31 Jan 2024 18:47:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA1673858416 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CA1673858416 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706726843; cv=none; b=koQpAzuFz0Bg/tsHU7KFllomn7P+6O+hyOZ9MINQ0tcTWfunsBiwIGuHhXEwLw5hQ+TAwjzX/ktznTMF7odWRNPxR04RkYNa56ibKl6rZeLG3XuJWpqlUiTBNYjphena9yrptVCdOk9gQevyk0rHMJ19yOltQmP+rKXt6Jj04bQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706726843; c=relaxed/simple; bh=YhPjZhMZ72K/ON9KOC9LEn0GxqS70EeOXuscevEEGl0=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=rHejWUAlZfzy6hUJnMeLhphG/7jezU885DVerdWFpSrWVtJe7z6fMSS/FLji8PNFb5V47kXPXr4lJq0x3vg+cfPSfxSxIgPF0aBYOYE7wabbciVIUVInVbzfcbv+Bm9UGrjg3sSexETydGxeCd9wOXupvY8qXxTlpWKbZU/2Alc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1706726840; bh=YhPjZhMZ72K/ON9KOC9LEn0GxqS70EeOXuscevEEGl0=; h=Subject:From:To:Date:In-Reply-To:References:From; b=izgDxsgns6h+EPrHiPxxCKBmA5wCD8nq4GIIgGgjfH6mDxn3YRsocw+/MktFR9UUM 0Q0jW03/DygIZu/rHwNHPncLHDYWCmwxAx69f0PXQ/j5/scLv+0K34hSF9o1kSPkM3 gHrvajwRykcJhPo/s4LkkIPHk72JJKpXRTbVrPFI= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id DC0CD670CC; Wed, 31 Jan 2024 13:47:19 -0500 (EST) Message-ID: <96521764f4636c9ea3f3089f369975c12fa8be77.camel@xry111.site> Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024 From: Xi Ruoyao To: Adhemerval Zanella Netto , Vincent Lefevre , Turritopsis Dohrnii Teo En Ming , "libc-alpha@sourceware.org" , "ceo@teo-en-ming-corp.com" Date: Thu, 01 Feb 2024 02:47:18 +0800 In-Reply-To: References: <20240131145555.GB2102@cventin.lip.ens-lyon.fr> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2024-01-31 at 12:52 -0300, Adhemerval Zanella Netto wrote: /* snip */ >=20 > I see this is an manual issue rather than a GNU 'extension' to qsort sema= ntic. > And I think we should fix BZ#31322 by using a transitive comparison inste= ad of > trying to support such cases. To me the documentation is correct (though arguably in a very subtle way): Here is an example of a comparison function which works with an array of numbers of type =E2=80=98double=E2=80=99: int compare_doubles (const void *a, const void *b) { const double *da =3D (const double *) a; const double *db =3D (const double *) b; return (*da > *db) - (*da < *db); } It says "numbers." But NaN literally means, "Not a Number." C23 says: Floating types shall be able to represent signed zeros or an unsigned zero and all normalized floating-point numbers. In addition, floating types may be able to contain other kinds of floating-point numbers, such as subnormal floating-point numbers and unnormalized floating-point numbers, and values that are not floating-point numbers, such as NaNs and (signed and unsigned) infinities. A NaN is a value signifying Not- a-Number. So at least in C23 it's clear that NaN and infinite values are not numbers. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University