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=-4.4 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 32D041F8C6 for ; Mon, 30 Aug 2021 18:18:15 +0000 (UTC) Received: from localhost ([::1]:52970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKlrK-0006Xs-0q for normalperson@yhbt.net; Mon, 30 Aug 2021 14:18:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKlrG-0006X4-Q8 for bug-gnulib@gnu.org; Mon, 30 Aug 2021 14:18:10 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56148) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKlrD-0007o0-ST for bug-gnulib@gnu.org; Mon, 30 Aug 2021 14:18:10 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3AE791600BC; Mon, 30 Aug 2021 11:18:05 -0700 (PDT) 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 drgzA279Krxc; Mon, 30 Aug 2021 11:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6E673160111; Mon, 30 Aug 2021 11:18:00 -0700 (PDT) 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 hDMPCU0fi1Lj; Mon, 30 Aug 2021 11:18:00 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 441081600BC; Mon, 30 Aug 2021 11:18:00 -0700 (PDT) To: Simon Josefsson , Bruno Haible References: <20210827222756.530247-1-eggert@cs.ucla.edu> <87tuj8pspu.fsf@latte.josefsson.org> <4787795.FjKLVJYuhi@omega> <877dg3nhrv.fsf@latte.josefsson.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH] base32, base64: prefer signed to unsigned integers Message-ID: Date: Mon, 30 Aug 2021 11:17:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <877dg3nhrv.fsf@latte.josefsson.org> Content-Type: multipart/mixed; boundary="------------D617A1659FDCE02C7DBBE217" Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -50 X-Spam_score: -5.1 X-Spam_bar: ----- X-Spam_report: (-5.1 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.932, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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: Gnulib bugs Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" This is a multi-part message in MIME format. --------------D617A1659FDCE02C7DBBE217 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 8/30/21 7:12 AM, Simon Josefsson wrote: > Thanks for the pointer -- it doesn't say anything about why ssize_t > can't be used though? As a signed variant of size_t, it seems relevant > to consider. Good question. Addressed in the attached patch, which I pushed. >> The objective is to eliminate bugs due to the use of unsigned types >> for numerical values. >=20 > Is that a realistic goal with C using the unsigned type size_t for > low-level functions like strlen()? It seems like an un-idiomatic goal. It is realistic, at least within the Gnulib context. It's also realistic=20 in the context of Glibc, which has recently started to prohibit heap=20 allocations larger than PTRDIFF_MAX for the usual security/correctness=20 reasons. The attached patch also attempts to address this question. > My idea was that both APIs would be supported indefinitely. Bruno already addressed this point, and I tend to agree with him for=20 this particular API. --------------D617A1659FDCE02C7DBBE217 Content-Type: text/x-patch; charset=UTF-8; name="0001-idx-add-commentary.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-idx-add-commentary.patch" =46rom 763dad031043b0342c825a8a05ca2fa28e9d905e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 30 Aug 2021 11:15:20 -0700 Subject: [PATCH] idx: add commentary * lib/idx.h: Add comments about ssize_t and strlen, in response to comments from Simon Josefsson in: https://lists.gnu.org/r/bug-gnulib/2021-08/msg00196.html --- ChangeLog | 7 +++++++ lib/idx.h | 20 ++++++++++++++++++++ 2 files changed, 27 insertions(+) diff --git a/ChangeLog b/ChangeLog index b86a6c33a..1b1372cb7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2021-08-30 Paul Eggert + + idx: add commentary + * lib/idx.h: Add comments about ssize_t and strlen, in + response to comments from Simon Josefsson in: + https://lists.gnu.org/r/bug-gnulib/2021-08/msg00196.html + 2021-08-29 Paul Eggert =20 attribute: keep up with gnulib-common.m4 diff --git a/lib/idx.h b/lib/idx.h index 483587eab..54ad5d81f 100644 --- a/lib/idx.h +++ b/lib/idx.h @@ -56,6 +56,26 @@ * Because 'size_t' is an unsigned type, and a signed type is better= =2E See above. =20 + Why not use 'ssize_t'? + + * 'ptrdiff_t' is more portable; it is standardized by ISO C + whereas 'ssize_t' is standardized only by POSIX. + + * 'ssize_t' is not required to be as wide as 'size_t', and some + now-obsolete POSIX platforms had 'size_t' wider than 'ssize_t'. + + * Conversely, some now-obsolete platforms had 'ptrdiff_t' wider + than 'size_t', which can be a win and conforms to POSIX. + + Won't this cause a problem with objects larger than PTRDIFF_MAX? + + * Typical modern or large platforms do not allocate such objects, + so this is not much of a problem in practice; for example, you + can safely write 'idx_t len =3D strlen (s);'. To port to older + small platforms where allocations larger than PTRDIFF_MAX could + in theory be a problem, you can use Gnulib's ialloc module, or + functions like ximalloc in Gnulib's xalloc module. + Why not use 'ptrdiff_t' directly? =20 * Maintainability: When reading and modifying code, it helps to kno= w that --=20 2.30.2 --------------D617A1659FDCE02C7DBBE217--