From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 9E4F83858D3C for ; Thu, 26 Aug 2021 16:24:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E4F83858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C312B1600C5; Thu, 26 Aug 2021 09:24:28 -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 NleAgAWtQhVA; Thu, 26 Aug 2021 09:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 02C041600D4; Thu, 26 Aug 2021 09:24:28 -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 gmt4-9GofH-q; Thu, 26 Aug 2021 09:24:27 -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 D41DE1600BE; Thu, 26 Aug 2021 09:24:27 -0700 (PDT) To: Martin Sebor Cc: GNU C Library References: <15a32181-8060-4135-cb72-9e79831697d5@gmail.com> <4251e9f2-d4d1-b649-8e86-a4336164a5b1@cs.ucla.edu> <1024a9e9-a880-7da2-7b99-3e8b8012a94a@cs.ucla.edu> <3e8fa13e-14e4-0e98-18e2-952cf5e9c278@cs.ucla.edu> <7e615633-ef4e-87b7-2808-8042a565911d@gmail.com> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH v3] remove attribute access from regexec Message-ID: <745a8432-57b9-134b-7024-c7ddbe9bc1da@cs.ucla.edu> Date: Thu, 26 Aug 2021 09:24:27 -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: <7e615633-ef4e-87b7-2808-8042a565911d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:24:30 -0000 On 8/26/21 8:06 AM, Martin Sebor wrote: >> >>> +#ifndef __ARG_NELTS >>> +# ifdef __ARG_NELTS >> >> A clear typo. The suggestion was to define and use _ARG_NELTS_ instead= . >=20 > __ARG_NELTS is=C2=A0 the name of macro in cdefs.h that you suggested so > this should presumably be the same, no? No matter what the macro name is (let's call it N), it cannot be right=20 to do this: #ifndef N # ifdef N ... whatever ... because the "whatever" cannot be reached. Unfortunately this is what=20 your patch does, with N being __ARG_NELTS. > I see you have both __ARG_NELTS and > _ARG_NELTS_ in your Gnulib patch though I don't understand why. It's for the same reason that regex.h already has both __restrict_arr=20 (the normal glibc practice) and _Restrict_arr_ (an alternative spelling=20 used only in regex.h). This is because regex.h is used both in=20 /usr/include on GNU systems (where __restrict_arr is used) and in Gnulib=20 on non-GNU systems that may not have __restrict_arr. regex.h does not simply #define __restrict_arr if it's not already=20 defined, because any such definition might collide with a later=20 GNU-system header that defines __restrict_arr in a different way (this=20 could happen if Gnulib regex.h is used on a older GNUish platform). Obviously this is a messy situation and I'd like to clean it up, but as=20 I mentioned in my previous email any such cleanup something better left=20 for a later patch. In the meantime we should just continue existing=20 practice when we add a new macro like __ARG_NELTS. > I plan to commit the last revision of the patch as is Please don't do that. That patch still needs work. Instead, please start=20 with the patch I sent, and understand what it does. Unless I'm missing=20 something it should be able to go into glibc as-is (though you may need=20 to edit glibc files that are not in gnulib).