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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, 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 0A7881F4B4 for ; Wed, 7 Apr 2021 21:01:40 +0000 (UTC) Received: from localhost ([::1]:34200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUFIw-0000bf-Qy for normalperson@yhbt.net; Wed, 07 Apr 2021 17:01:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40802) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUFIs-0000bD-UW for bug-gnulib@gnu.org; Wed, 07 Apr 2021 17:01:34 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]:32673) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUFIq-0002tg-MB for bug-gnulib@gnu.org; Wed, 07 Apr 2021 17:01:34 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1617829289; cv=none; d=strato.com; s=strato-dkim-0002; b=IbGMsSpPEtx+SIImqbVNjAH8ngDrrbAW9HDOzDBzrbwnzcL82SzFXJl4fq98M4ec8i MCgROnbRO8qJLTdCY1v9GkM6Iqovxp8IzjzIt6+gXf43FzVm0fa4Tv1Snt7qNK6GIiwl RG7g1Zb3nOMycSLiV4Q2ii1qNnv0feLMPD7FcKC8+jsr5IvjeKhiqnHXfmflrkvemFn/ t7npo9dTiYbT+b+SeRYcXYqXiAzRlPgrNPNvidtQ1Efj79ABlX5LUhLh5q4U7f81FSNj ARo/Xds37FOYS/vuakYau/3uM7eUOTdD6kcDXJtffCiSHm29oyGuC2xhmIl0wOXqZSeQ HaPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1617829289; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=ctCMqhge2Mx77oWQ3LLIr8zYvJKBLibgab6EzwuOLhk=; b=gxwXds0B+ZSRPSCTzMo2o+X8H3NDrEsRr2zmC8qSCBgJPp/PymC31RPuVXB8gziP2G AvOtZhOjpFs5j1+hRPh28Bn1CpBBQcG4/ygfMNQqf1atrvd1iYsZjgu0hnckx0pIVvTy MnENgtNATRIerQXYJzsfcVGuBwN7PFbSkPmxCUix72Uhbs5UYFbaK/W+3BSwTN5T3tDd FFomejLwsL1gssqaMwhIcOpbMr7bBSfxuj5sytv6lJAEmb3rK3rBn8uKMBESryCjbci1 a0WBZU1Wf44rvMSxWHgPYT2FvOqNKVLJq9ZWSQyppys9eyqnMzP+OKYPg6AGeBe7tCp2 kdqA== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1617829289; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=ctCMqhge2Mx77oWQ3LLIr8zYvJKBLibgab6EzwuOLhk=; b=i8dxs6KJlDIz7Pf0N1AkVAWlzbKnPgwmp2QIIXCFK5P34GrMWGqD/7nn9PShvRQ7OG BkUfja8xvQrGD8SzUuU7La699fpoesXyu4OyxGN3dKtN+o7SS54y/3ZMLfVmoFt4uSIV avKYGVArBZ8e0Ii5JG1olQllLTr2XpzNzustdr7VGOHjLf7DCOMPvZnZ0fM5lhld4G89 UkNJpsxagfvlk8OAVGwWxCCPg4gX6lDpW3jzphHFw0UKAyjR4j6KYqnDDgKI6CTilLUe srm1Is9iaaMYJTo2MTe7+tH8VQ426yENLqGZtl+RdxD8Ml//S0QH5wNEJSzBGKiO2H/4 S3Pg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf0y5JW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.24.0 DYNA|AUTH) with ESMTPSA id 5024b1x37L1S1IC (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 7 Apr 2021 23:01:28 +0200 (CEST) From: Bruno Haible To: Paul Eggert Subject: Re: xalloc.h use idx_t Date: Wed, 07 Apr 2021 23:01:28 +0200 Message-ID: <7226106.K2Z7k6o9bv@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <089b97c0-368b-6332-0312-db600718de4c@cs.ucla.edu> References: <089b97c0-368b-6332-0312-db600718de4c@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.219; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=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: Marc =?ISO-8859-1?Q?Nieper=2DWi=DFkirchen?= , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Paul, > I am planning to make xalloc.h use idx_t rather than size_t for object > and byte counts, as we really should be using signed integers there, for > all the usual reasons. I agree that using idx_t in more places helps reduce overflow problem. However, since 'xalloc' started out as "malloc() which can't return NULL", this would introduce an inconsistency w.r.t. malloc(). Could programmers still replace calls to malloc() with calls to xmalloc() without thinking, without considering the context? And vice versa, when transforming code into library code, can programmers still replace calls to xmalloc() with calls to malloc() and a NULL check, mechanically? (I hope the answer is "yes", but maybe I'm overlooking something?) Bruno