From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 208.118.235.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2BCAF1F770 for ; Mon, 31 Dec 2018 01:41:05 +0000 (UTC) Received: from localhost ([127.0.0.1]:47731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdmZk-0000jN-Ba for normalperson@yhbt.net; Sun, 30 Dec 2018 20:41:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdmZf-0000jG-W6 for bug-gnulib@gnu.org; Sun, 30 Dec 2018 20:41:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gdmZX-0006Ng-Ls for bug-gnulib@gnu.org; Sun, 30 Dec 2018 20:40:57 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44162) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gdmZV-00066I-LM for bug-gnulib@gnu.org; Sun, 30 Dec 2018 20:40:51 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3BC0F160E52; Sun, 30 Dec 2018 17:40:43 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kMcdAFhmuYip; Sun, 30 Dec 2018 17:40:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5E81C160E5A; Sun, 30 Dec 2018 17:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5mt8gV2T-8v6; Sun, 30 Dec 2018 17:40:42 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2EF9D160E19; Sun, 30 Dec 2018 17:40:42 -0800 (PST) Subject: Re: new module suggestion: fprintftime-check To: Ben Pfaff References: <5c116236-dfd7-9bd9-a18e-3e55789ae985@gmail.com> <42958301.nlEivnNqOc@omega> <20181229174815.GH6178@sigabrt.benpfaff.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 30 Dec 2018 17:40:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181229174815.GH6178@sigabrt.benpfaff.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, Assaf Gordon , Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Ben Pfaff wrote: > On Sat, Dec 29, 2018 at 09:22:17AM -0800, Paul Eggert wrote: >> (Using ptrdiff_t is part of my campaign to prefer ptrdiff_t to size_t. While >> we're at it, let's change the other size_t args to ptrdiff_t, but I >> digress....) > > Have you said anything about this campaign elsewhere? I'd like to hear > more. I probably have, but it's easier for me to say something new afresh. The C standard says that objects with size greater than PTRDIFF_MAX can cause trouble, because subtracting pointers into these objects yields undefined behavior if the resulting integer does not fit into ptrdiff_t. Worse, on many popular systems (including GNU), even if (P - Q)'s value fits into ptrdiff_t, (P - Q) can be calculated incorrectly if ((char *) P - (char *) Q) does not fit into ptrdiff_t; although this behavior is contrary to the C standard it's such a common problem that we cannot ignore it in portable code. Because of this, C code should never allocate objects with size greater than PTRDIFF_MAX unless it never does pointer subtraction with the result, and it's generally simpler and more reliable if C code simply refuses to allocate such objects under any circumstances. Gnulib started doing this a couple of years ago with commit f3b846699de69b8e6a508396f7f778eb1e917a47, which causes xalloc-oversized and related modules to reject attempts to create objects larger than PTRDIFF_MAX bytes; this means many GNU applications are already safer. (Emacs has a different way of enforcing the same restriction internally.) Also, we are thinking of doing something similar with glibc's malloc/etc. functions in the next glibc version, though this patch has not gone in yet and may have to wait until the version after next. As a result, C programs can now use either size_t or ptrdiff_t to store object sizes, since no actual object can have more than min (SIZE_MAX, PTRDIFF_MAX) bytes. Using signed types is better nowadays than using unsigned types, since many platforms now check for signed integer overflow and this can catch many bugs, some of them security-relevant, whereas unsigned arithmetic is well defined to wrap around with no overflow check (something that can be quite dangerous when doing size calculations). So, for reliability and security reasons, C programs should now prefer ptrdiff_t to size_t when dealing with object sizes.