From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by sourceware.org (Postfix) with ESMTPS id 82F8A3858D3C for ; Thu, 26 Aug 2021 15:06:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82F8A3858D3C Received: by mail-qk1-x729.google.com with SMTP id b64so3815243qkg.0 for ; Thu, 26 Aug 2021 08:06:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z9R/8xcSQKn2CTT+A0PM3H6HxPIPYmLUtUIqsseE8+U=; b=AeJrXMoEwPwkUy+EQ/3ECAgYn9OuauJrxDq36yjjBgfta1njaW+x0JaoQhdddr9yGk kP6z18Euq99JAgfKCGw/MJFo/+vn9u75p7bKDUvPARpT/f0MXE1acFfPhtQQ/ZLLiC4A yc7VQjxT6rB0vmFkMxZXaE6cRQ0UHFSZrW5RBDOw0bIDT8hjgqUtRQ8HapmCwLTmcMR7 CrH+cV7JEipEhQ/tLDrvweoj4J4hdSlqoee+KhGD1zjw1lexyfH+yX0VyYx8781Dn1Qx 6LVVx901LA5YTKqUaIC7ZsCv2GH1EuLY50O4UL51GfWZTKK5cfojJ2gMwZhyt4MmPEA+ Q+CA== X-Gm-Message-State: AOAM533ipuwJOLcTmIiKNnTa7r5WrbDE+23nhdiV9PXSgsLXzLxbK8KN KfwOaEiDbHnz1KmRNF4COdoe4tggfSc= X-Google-Smtp-Source: ABdhPJwQGsdGBykqAFpMAJ5AepyDvEOmDo2wTJg/dr2Xzvysyz4nlZe1tvcFtF7+MxacDSKYXJ+8ng== X-Received: by 2002:a37:aa82:: with SMTP id t124mr4043500qke.293.1629990365004; Thu, 26 Aug 2021 08:06:05 -0700 (PDT) Received: from [192.168.0.41] (97-118-104-61.hlrn.qwest.net. [97.118.104.61]) by smtp.gmail.com with ESMTPSA id g20sm2584704qki.73.2021.08.26.08.06.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 08:06:04 -0700 (PDT) Subject: Re: [PATCH v3] remove attribute access from regexec To: Paul Eggert 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> From: Martin Sebor Message-ID: <7e615633-ef4e-87b7-2808-8042a565911d@gmail.com> Date: Thu, 26 Aug 2021 09:06:03 -0600 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: <3e8fa13e-14e4-0e98-18e2-952cf5e9c278@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 15:06:07 -0000 On 8/21/21 11:06 PM, Paul Eggert wrote: > On 8/19/21 4:50 PM, Martin Sebor wrote: > >> Is for some reason not considered a system header in your >> test environment? > > Yes, because Coreutils etc. currently use Gnulib regex.h instead of > /usr/include/regex.h, as Glibc regex has a bug and the fix (in Gnulib) > hasn't made its way back to Glibc yet. > > This sort of thing is all too common, as regex development (such as it > is) often occurs in Gnulib first, which means it's common for > 'configure' to discover that the current Glibc has a bug and to > substitute Gnulib regex instead. And when we compile Gnulib headers we > don't consider them to be system headers, because we want the extra > static checking that gcc does for non system headers. > > I think the simplest workaround for the warning is to disable -Wvla for > that particular declaration. Please see attached Gnulib patch for how I > suggest doing this. > >> I didn't know mixing and matching two implementations like this >> was even possible.  Thanks for explaining it (though it seems >> like a pretty cumbersome arrangement). > > Yes, it is a bit awkward. I am tempted to clean it up but that really > should be a separate patch and so I will focus only on this thread's issue. > >> +#ifndef __ARG_NELTS >> +# ifdef __ARG_NELTS > > A clear typo. The suggestion was to define and use _ARG_NELTS_ instead. __ARG_NELTS is the name of macro in cdefs.h that you suggested so this should presumably be the same, no? (I.e., it's not a typo but I could be missing something.) > > Some other thoughts. > > If we're going to change regexec, we should change __compat_regex to be > consistent. > > We should also change regexec.c's internal functions to be consistent > with regexec. This includes re_search_internal, update_regs, etc. That sounds like a good idea for a follow-up. My immediate goal is to avoid the current warning so Glibc can build, and I prefer to make that change independently of other improvements. I plan to commit the last revision of the patch as is unless there's some reason I'm missing that the name of the regex.h macro shouldn't be the same as that in cdefs.h. I see you have both __ARG_NELTS and _ARG_NELTS_ in your Gnulib patch though I don't understand why. Thanks for all your comments! Martin > > These internal functions don't have regexec's quirk that pmatch is > ignored when not substituting, so their parameters can use the syntax > "regmatch_t pmatch[__ARG_NELTS (static nmatch)]" to let the compiler > know that the array must be of the given size. > > Proposed Gnulib patch attached. It should be easy to aplly to glibc > though glibc also needs its own regex.h patched. I have not installed > this into Gnulib yet. > > At some point we should sync Gnulib and Glibc regex of course.