public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] remove attribute access from regexec
Date: Fri, 13 Aug 2021 15:30:02 -0600	[thread overview]
Message-ID: <e2867697-4dee-f268-caba-0f4f7cec94ed@gmail.com> (raw)
In-Reply-To: <e6e61bff-fa9f-6315-0ffe-911c89250174@cs.ucla.edu>

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On 8/13/21 2:11 PM, Paul Eggert wrote:
> On 8/13/21 11:26 AM, Martin Sebor via Libc-alpha wrote:
>> -    __attr_access ((__write_only__, 4, 3));
>> +    __attr_access ((__read_write__, 4, 3));
> 
> Wouldn't it be simpler to remove the __attr_access instead?
> 
> What utility does __attr_access ((__read_write__, 4, 3)) have? FWIW, 
> Glibc currently does not use such an attribute anywhere.

The attribute serves two purposes: it specifies 1) how the function
might access the array (to determine whether it should be initialized
by the caller) and 2) the minimum number of elements the caller must
provide and the maximum number of elements the function definition
might access.

GCC checks to make sure these constraints are satisfied, both at call
sites and in the definitions of these functions.

The read_write mode means that a function may both read from and write
to the array, and expects it to be initialized.  But since regexec
might just write to the array and not read from it, depending on
flags, the read_write mode wouldn't be correct either.

There is no attribute access mode that would capture this but in C99
(though sadly not in C++) and thanks to the nmatch argument preceding
pmatch, the VLA argument syntax does make the checking possible.  It's
like attribute access with an unspecified mode.  (It might be worth
extending the attribute to express this mode so it can be used when
the bound doesn't precede the VLA argument and in C++.)

Attached is a revised patch with this approach.

Martin

PS POSIX says regexec() ignores pnmatch when REG_NOSUB is set, so
strictly speaking, warning for such calls to it in that case is
also a false positive.  I think that's an acceptable trade-off for
the buffer overflow detection (passing a zero nmatch in that case
is a trivial way to avoid the warning).

[-- Attachment #2: glibc-28170.diff --]
[-- Type: text/x-patch, Size: 1753 bytes --]

diff --git a/include/regex.h b/include/regex.h
index 24eca2c297..d67ec65ad9 100644
--- a/include/regex.h
+++ b/include/regex.h
@@ -36,8 +36,15 @@ extern void __re_set_registers
 extern int __regcomp (regex_t *__preg, const char *__pattern, int __cflags);
 libc_hidden_proto (__regcomp)
 
+#if 199901L <= __STDC_VERSION__ && !defined (__STDC_NO_VLA__)
 extern int __regexec (const regex_t *__preg, const char *__string,
-		      size_t __nmatch, regmatch_t __pmatch[], int __eflags);
+		      size_t __nmatch, regmatch_t __pmatch[__nmatch],
+		      int __eflags);
+#else
+extern int __regexec (const regex_t *__preg, const char *__string,
+		      size_t __nmatch, regmatch_t __pmatch[],
+		      int __eflags);
+#endif
 libc_hidden_proto (__regexec)
 
 extern size_t __regerror (int __errcode, const regex_t *__preg,
diff --git a/posix/regex.h b/posix/regex.h
index 14fb1d8364..ebacbaf95d 100644
--- a/posix/regex.h
+++ b/posix/regex.h
@@ -652,11 +652,17 @@ extern int regcomp (regex_t *_Restrict_ __preg,
 		    const char *_Restrict_ __pattern,
 		    int __cflags);
 
+#if 199901L <= __STDC_VERSION__ && !defined (__STDC_NO_VLA__)
 extern int regexec (const regex_t *_Restrict_ __preg,
 		    const char *_Restrict_ __String, size_t __nmatch,
-		    regmatch_t __pmatch[_Restrict_arr_],
-		    int __eflags)
-    __attr_access ((__write_only__, 4, 3));
+		    regmatch_t __pmatch[_Restrict_arr_ __nmatch],
+		    int __eflags);
+#else
+extern int regexec (const regex_t *_Restrict_ __preg,
+		    const char *_Restrict_ __String, size_t __nmatch,
+		    regmatch_t __pmatch[_Restrict_arr],
+		    int __eflags);
+#endif
 
 extern size_t regerror (int __errcode, const regex_t *_Restrict_ __preg,
 			char *_Restrict_ __errbuf, size_t __errbuf_size)

  reply	other threads:[~2021-08-13 21:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 18:26 Martin Sebor
2021-08-13 20:11 ` Paul Eggert
2021-08-13 21:30   ` Martin Sebor [this message]
2021-08-13 22:34     ` Paul Eggert
2021-08-14 20:08       ` Martin Sebor
2021-08-18 15:53         ` [PATCH v2] " Martin Sebor
2021-08-18 19:52         ` [PATCH] " Paul Eggert
2021-08-19 23:50           ` [PATCH v3] " Martin Sebor
2021-08-22  5:06             ` Paul Eggert
2021-08-26 15:06               ` Martin Sebor
2021-08-26 16:24                 ` Paul Eggert
2021-08-26 16:47                   ` Martin Sebor
2021-08-27  8:52                     ` Paul Eggert
2021-08-27 16:34                       ` Martin Sebor
2021-08-27 17:50                         ` Allow #pragma GCC in headers in conformtest [committed] (was: Re: [PATCH v3] remove attribute access from regexec) Joseph Myers
2021-08-27 18:57                         ` [PATCH v3] remove attribute access from regexec Paul Eggert
2021-09-20 20:46                           ` Joseph Myers
2021-09-21  6:52                             ` Paul Eggert
2021-09-21 13:48                               ` Joseph Myers
2021-09-21 15:00                                 ` Paul Eggert
2021-10-19 16:39             ` Carlos O'Donell
2021-10-19 17:06               ` Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2867697-4dee-f268-caba-0f4f7cec94ed@gmail.com \
    --to=msebor@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).