From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from joooj.vinc17.net (joooj.vinc17.net [155.133.131.76]) by sourceware.org (Postfix) with ESMTPS id DEF6A385840A for ; Thu, 1 Feb 2024 09:07:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEF6A385840A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vinc17.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=vinc17.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DEF6A385840A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=155.133.131.76 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706778450; cv=none; b=JnKqT8pZXOLEq3uoho5XO73jAjbZ1OOOQWoWPC/Jjm05tjWoJ19YoB1Y0JzJXiFk5psUI//HUau4hau4b404YvaxhyZlNgrJHtjet98ajgrCo+3GkyeO0LKMnO8YgnR2+To88VTiqJumjkDCVPVecksWnW9QixGAFd0wsw2oRJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706778450; c=relaxed/simple; bh=12kuJrOUIt97D82eu6APFYDTaj2j7fy0Kf/CFqh1IW0=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=w55ROAe5BQeb76bpDbuP+AB6VSYmbsxQxf251fPjgiEzq3AeH+UA0wu2DqCqZdkNif23JYM81zo82mSZSXv2hMExUxvmbfl+aLKG02EdQhnkMVBeEx2lw/AkKMegIue1yj2YWXO52/85M1l8CyImENZuMGzWOGAuwj+oOiWXk/Y= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp-qaa.vinc17.net (135.197.67.86.rev.sfr.net [86.67.197.135]) by joooj.vinc17.net (Postfix) with ESMTPSA id A0FB723D; Thu, 1 Feb 2024 10:07:22 +0100 (CET) Received: by qaa.vinc17.org (Postfix, from userid 1000) id C1156CA00B2; Thu, 1 Feb 2024 10:07:21 +0100 (CET) Date: Thu, 1 Feb 2024 10:07:21 +0100 From: Vincent Lefevre To: Xi Ruoyao Cc: Adhemerval Zanella Netto , Turritopsis Dohrnii Teo En Ming , "libc-alpha@sourceware.org" , "ceo@teo-en-ming-corp.com" Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024 Message-ID: <20240201090721.GH3044@qaa.vinc17.org> Mail-Followup-To: Vincent Lefevre , Xi Ruoyao , Adhemerval Zanella Netto , Turritopsis Dohrnii Teo En Ming , "libc-alpha@sourceware.org" , "ceo@teo-en-ming-corp.com" References: <20240131145555.GB2102@cventin.lip.ens-lyon.fr> <96521764f4636c9ea3f3089f369975c12fa8be77.camel@xry111.site> <20240201005155.GF3044@qaa.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.12+69 (354c5b11) vl-149028 (2023-12-10) X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-02-01 14:41:04 +0800, Xi Ruoyao wrote: > On Thu, 2024-02-01 at 01:51 +0100, Vincent Lefevre wrote: > > On 2024-02-01 02:47:18 +0800, Xi Ruoyao wrote: > > > On Wed, 2024-01-31 at 12:52 -0300, Adhemerval Zanella Netto wrote: > > > > > > /* snip */ > > > > > > > > > > > I see this is an manual issue rather than a GNU 'extension' to qsort semantic. > > > > And I think we should fix BZ#31322 by using a transitive comparison instead 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 ‘double’: > > > > > >      int > > >      compare_doubles (const void *a, const void *b) > > >      { > > >        const double *da = (const double *) a; > > >        const double *db = (const double *) b; > > > > > >        return (*da > *db) - (*da < *db); > > >      } > > > > > > It says "numbers."  But NaN literally means, "Not a Number." > > > > Yes, the point is to sort numbers. But since NaN may occur, the code > > must not yield undefined behavior in such a case. This is the goal > > of NaN: avoid undefined behavior for operations that do not make any > > sense, and be able to detect errors at the end. > > When we sort *numbers* NaN cannot be passed to the comparator. What I mean is that the intent is to sort numbers. But in any case, the code needs to consider that NaN may occur; the result would be an array in an indeterminate order, but the code must not produce undefined behavior with consequences like memory corruption. If the code is designed considering that NaN cannot occur, e.g. because the user is required to ensure that before calling qsort, then this must explicitly be documented with a non-ambiguous vocabulary (typically using "assume"). > And I doubt if silently producing a NaN is really good for error > detection. Simply crashing when an invalid operation happens is > easier for debugging, IMO. And it's possible with "feenableexcept > (FE_INVALID)" (where FP exceptions are supported). Silently producing a NaN on "invalid" inputs is what happens in practice, following the spec of the IEEE 754 standard. For instance, sqrt(-1.) silently returns NaN (a flag is also set). But in general, the user will not check for NaN (by testing the value or the flag) after every operation/function, even when it is known that they can generate a NaN. He will let NaN propagate (the flag can also be checked later as it is sticky). Note also that getting a NaN does not necessarily mean that the program is buggy: after a sequence of computations, there may be code to decide what to do when a NaN is obtained. So enabling traps for FE_INVALID is not necessarily correct. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)