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 156F91F463 for ; Mon, 16 Dec 2019 09:56:22 +0000 (UTC) Received: from localhost ([::1]:49414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ign6y-00086e-Ig for normalperson@yhbt.net; Mon, 16 Dec 2019 04:56:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39999) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ign6v-00086S-6J for bug-gnulib@gnu.org; Mon, 16 Dec 2019 04:56:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ign6t-0006D8-Nu for bug-gnulib@gnu.org; Mon, 16 Dec 2019 04:56:16 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54026) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ign6t-0006Ct-HZ for bug-gnulib@gnu.org; Mon, 16 Dec 2019 04:56:15 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1E2C01600FC; Mon, 16 Dec 2019 01:56:14 -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 iwD4f3uTtqnJ; Mon, 16 Dec 2019 01:56:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D0A91605CA; Mon, 16 Dec 2019 01:56:13 -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 BDGSEVE_XzVz; Mon, 16 Dec 2019 01:56:13 -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 35D401600FC; Mon, 16 Dec 2019 01:56:13 -0800 (PST) Subject: Re: bug#34951: [PATCH] grep: a kwset matcher not work in a grep matcher To: arnold@skeeve.com, jim@meyering.net References: <20190323080618.E6EB.27F6AC2D@kcn.ne.jp> <20190323114902.E6F6.27F6AC2D@kcn.ne.jp> <75091466-e105-c35c-fcd6-19ccca325914@cs.ucla.edu> <201912120731.xBC7V6gD031767@freefriends.org> <38194689-56ba-41f4-3810-50df1ff9019c@cs.ucla.edu> <201912130809.xBD89uUG021729@freefriends.org> <201912131208.xBDC8QLo032709@freefriends.org> <20db9cb5-da09-fe26-f7fc-884fc194daaa@cs.ucla.edu> <201912150814.xBF8EOXW005059@freefriends.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <206e5f61-2c80-d6f0-c4a7-b7365c0b523d@cs.ucla.edu> Date: Mon, 16 Dec 2019 01:56:12 -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: <201912150814.xBF8EOXW005059@freefriends.org> 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: 34951@debbugs.gnu.org, bug-gnulib@gnu.org, noritnk@kcn.ne.jp Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 12/15/19 12:14 AM, arnold@skeeve.com wrote: > int64_t is just as standard as ptrdiff_t and just as clear. Actually, int64_t is optional (as even C18 and POSIX-2018 do not require it), whereas ptrdiff_t has been required since C89. More importantly, int64_t would be overkill on 32-bit GNU/Linux, whereas ptrdiff_t suffices and is typically more efficient. (Besides, what would we do if 72-bit pointers came back into vogue? :-)