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 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 323271F463 for ; Sat, 28 Dec 2019 18:29:02 +0000 (UTC) Received: from localhost ([::1]:45446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilGpg-0000lc-Kp for normalperson@yhbt.net; Sat, 28 Dec 2019 13:29:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58269) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilGpZ-0000lV-Bl for bug-gnulib@gnu.org; Sat, 28 Dec 2019 13:28:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilGpY-0002vs-1H for bug-gnulib@gnu.org; Sat, 28 Dec 2019 13:28:53 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50852) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ilGpX-0002iU-P6 for bug-gnulib@gnu.org; Sat, 28 Dec 2019 13:28:51 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6A49916018B; Sat, 28 Dec 2019 10:28:49 -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 WCpUjs4a6VbE; Sat, 28 Dec 2019 10:28:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B4E27160502; Sat, 28 Dec 2019 10:28:47 -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 h7Kv0rZ5X_b1; Sat, 28 Dec 2019 10:28:47 -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 8828B16018B; Sat, 28 Dec 2019 10:28:47 -0800 (PST) Subject: Re: string types To: ag , bug-gnulib@gnu.org, Bruno Haible References: <175192568.e2XXTFFdkW@omega> <20191226221225.GA800@HATZ> <2179574.G9OhZXe8sF@omega> <20191228131438.GA797@HATZ> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <1c20e1d7-33fa-292a-731f-d2e5b56acb6d@cs.ucla.edu> Date: Sat, 28 Dec 2019 10:28:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191228131438.GA797@HATZ> Content-Type: text/plain; charset=utf-8 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.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Tim_R=c3=bchsen?= Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 12/28/19 5:14 AM, ag wrote: > - PTRDIFF_MAX is at least INT_MAX and at most SIZE_MAX > (PTRDIFF_MAX is INT_MAX in 32bit) PTRDIFF_MAX can exceed SIZE_MAX, in the sense that POSIX and C allows it and it could be useful on 32-bit platforms for size_t to be 32 bits and ptrdiff_t to be 64 bits. Although I don't know of any platforms doing things that way, I prefer not to assume that PTRDIFF_MAX <= SIZE_MAX so as to allow for the possibility. > - SIZE_MAX as (size_t) (-1) > > - ssize_t (s means signed?) can be as big as SIZE_MAX? and SSIZE_MAX equals to > SIZE_MAX? ssize_t can be either narrower or wider than size_t, according to POSIX. Historically ssize_t was 32 bits and size_t 64 bits on some platforms, and though I don't know of any current platforms doing that it's easy to not make assumptions here. > Based on the above assumptions this can be extended. First instead of size_t to > return ssize_t, so functions can return -1 and set errno accordingly. It's better to use ptrdiff_t for this sort of thing, since it's hardwired into the C language (you can't do any better than ptrdiff_t anyway, if you use pointer subtraction), whereas ssize_t is merely in POSIX and is narrower than ptrdiff_t on some (obsolete?) platforms. > In my humble opinion there is also the choise to choose reallocarray() from OpenBSD, > which always checks for integer overflows with the following way: > > #define MUL_NO_OVERFLOW ((size_t) 1 << (sizeof (size_t) * 4)) > #define MEM_IS_INT_OVERFLOW(nmemb, ssize) \ > (((nmemb) >= MUL_NO_OVERFLOW || (ssize) >= MUL_NO_OVERFLOW) && \ > (nmemb) > 0 && SIZE_MAX / (nmemb) < (ssize)) Ouch. That code is not good. An unsigned division at runtime to do memory allocation? Gnulib does better than that already. Also, Glibc has some code in this area that we could migrate into Gnulib, that could be better yet.