[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] regex: use C99-style array arg syntax
From: |
Paul Eggert |
Subject: |
Re: [PATCH] regex: use C99-style array arg syntax |
Date: |
Fri, 27 Aug 2021 00:55:26 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 8/26/21 4:58 PM, Bruno Haible wrote:
Oops, my suggestion was not right. Instead, what needs to be done
in order to preserve good diagnostics with GCC 10 is to keep the
__access__ attribute, even with the VLA.
Yes, it appears I was too ambitious in my patch. I have reverted much of
it and the result is that yesterday's regex patches (counting the typo
fix), when combined, amount to the attached.
To answer some of your earlier questions, here are some examples:
void f (int n, int *a) { }
void g (int n, int a[n]) { }
void h (int n, int a[static n]) { }
__attribute__ ((access (read_write, 2, 1))) void i (int n, int *a) { }
f and g are the same, except that (1) a conforming C11 compiler can
reject g if __STDC_NO_VLA__ is defined, (2) if you use g's style in a
function declaration you should also use g's style in the function's
definition (otherwise there's a type-compatibility problem), recent
versions of GCC can warn if you pass an array to g whose size is too
small for n.
h differs from g in that the C standard requires that every call to h
must pass a null pointer to an array of at least n elements. (As you
say, the "at least" is redundant but the standard is intentionally
redundant here, to remove possibilities for confusion.) h is intended
for optimization, so that the compiler can generate code to access the
first n elements of a at function entry, regardless of whether the C
code actually accesses those elements. Such an optimization is not
allowed for f or g.
The syntax used for 'i' is more flexible and powerful than the syntax
used for h, which is why glibc is using i-like syntax. Among other
things, you can use i-like syntax only in a function declaration; you
need not repeat it in the function's definition.
Unfortunately, for regexec there is no i-like syntax that is
appropriate, since any of the access modes 'read', 'write',
'read_write', 'none' are incorrect for some valid and reasonable regexec
calls. Also, an h-like syntax is not appropriate since it's reasonable
to pass regexec a null pointer in some cases. Because of this, for
regexec we can use only f-like or g-like syntax. g-like syntax is better
when supported, as it lets GCC warn if you pass an array of
inappropriate size to regexec (this warning will be incorrect for valid
but screwy regexec calls, but that's OK).
My previous patch attempted to use i-like syntax for internal regex
functions. However, it's not clear it's worth doing that, and anyway
it's not necessary to solve the problem Martin Sebor originally raised
in
<https://sourceware.org/pipermail/libc-alpha/2021-August/130137.html>.
So my current patch limits itself to Martin's issue.
I'll CC this to Martin to let him know that my suggested patches have
hit Gnulib. The intent is to sync Gnulib to Glibc.
regex.diff
Description: Text Data