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 2788E3858D37 for ; Thu, 1 Feb 2024 01:03:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2788E3858D37 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 2788E3858D37 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=1706749418; cv=none; b=d/ClRw255cRqVfCDs1k30RzhUPnGx/Ctpb1RD8TxqK2JI3xwC6gk53gm4IuCYsJx7R1zY0xOKOXxQQZ2s3vU5N5V00t9Z/YAaYzrAiZuR9CokuwGjQbVQNb9pJcX8PMWHfGSGdCx2TBlH1alvLhjaQM3v3agw6IwvpVpHjdeGS0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706749418; c=relaxed/simple; bh=M0pmzuu64hV23naFRB2OlvHuwq4uf/lfxwqVDSbFxSg=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=tSZnNXpF5xoMSn3kErpsDCdSw/7VxXj0j5eskQy5+xGPkodltZePG8rlJzuDTuw9obQAIIbuX6NXaQeXiAwESP/iDsxlqIrY+UsgNzKFPThUF5X7egSEwZ9ond6t85bAdoEHlKJeS2Wi0JrRz80i44jEwJrdqUFFXI8uPc1QO0c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp-qaa.vinc17.net (2a02-8428-1b1d-4d01-96a9-491d-7b48-ba31.rev.sfr.net [IPv6:2a02:8428:1b1d:4d01:96a9:491d:7b48:ba31]) by joooj.vinc17.net (Postfix) with ESMTPSA id 2905F3DE; Thu, 1 Feb 2024 02:03:36 +0100 (CET) Received: by qaa.vinc17.org (Postfix, from userid 1000) id D0FD0CA00B2; Thu, 1 Feb 2024 02:03:35 +0100 (CET) Date: Thu, 1 Feb 2024 02:03:35 +0100 From: Vincent Lefevre To: Xi Ruoyao , 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: <20240201010335.GG3044@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240201005155.GF3044@qaa.vinc17.org> 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=-1.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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 2024-02-01 01:51:55 +0100, Vincent Lefevre wrote: > 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. BTW, note that the ISO C standard sometimes uses "number" even when this can be a NaN. For instance, in 7.12.7.2: The fabs functions compute the absolute value of a floating-point number x. (though this has been changed in C23). But the term "number" is still used in C23 for ceil and floor. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)