From: Martin Sebor <msebor@gmail.com>
To: Stefan Liebler <stli@linux.ibm.com>, libc-alpha@sourceware.org
Cc: msebor@redhat.com
Subject: Re: [PATCH] Fix stringop-overflow warning in bug-regex19.c.
Date: Wed, 12 May 2021 09:56:07 -0600 [thread overview]
Message-ID: <051c230f-b7a7-3403-f912-e85ac7bba1b6@gmail.com> (raw)
In-Reply-To: <20210512063345.2269779-1-stli@linux.ibm.com>
On 5/12/21 12:33 AM, Stefan Liebler via Libc-alpha wrote:
> Starting with commit
> 26492c0a14966c32c43cd6ca1d0dca5e62c6cfef
> "Annotate additional APIs with GCC attribute access.",
> gcc emits this warning on s390x:
> In function ‘do_one_test’,
> inlined from ‘do_mb_tests’ at bug-regex19.c:385:11:
> bug-regex19.c:271:9: error: ‘re_search’ specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
> 271 | res = re_search (®buf, test->string, strlen (test->string),
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 272 | test->start, strlen (test->string) - test->start, NULL);
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from ../include/regex.h:2,
> from bug-regex19.c:22:
> bug-regex19.c: In function ‘do_mb_tests’:
> ../posix/regex.h:554:17: note: in a call to function ‘re_search’ declared with attribute ‘read_only (2, 3)’
> 554 | extern regoff_t re_search (struct re_pattern_buffer *__buffer,
> | ^~~~~~~~~
> ...
>
> The function do_one_test is inlined into do_mb_tests on s390x (at least with
> gcc 10). If do_one_test is marked with __attribute__ ((noinline)), there are
> no warnings on s390x. If do_one_test is marked with
> __attribute__ ((always_inline)), there are the same warnings on x86_64.
>
> test->string points to a variable length array on stack of do_mb_tests
> and the content is generated based on the passed test struct.
This is a false positive caused by the same bug as the one in
nss/makedb.c. It's fixed in GCC 11 but the whole change is too
intrusive to backport to 10. I'll see if I can extract just
the fix itself and backport it.
Disabling inlining for the test function as a workaround seems
reasonable to me (a comment should probably be added mentioning
why it's being done). An alternative is to suppress the warning
using #pragma GCC diagnostic (as was done in nss/makedb.c).
Martin
> ---
> posix/bug-regex19.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/posix/bug-regex19.c b/posix/bug-regex19.c
> index 9bbffb17e3..fcae533762 100644
> --- a/posix/bug-regex19.c
> +++ b/posix/bug-regex19.c
> @@ -251,6 +251,7 @@ static struct test_s
> };
>
> int
> +__attribute__ ((noinline))
> do_one_test (const struct test_s *test, const char *fail)
> {
> int res;
>
next prev parent reply other threads:[~2021-05-12 15:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 6:33 Stefan Liebler
2021-05-12 15:56 ` Martin Sebor [this message]
2021-05-13 17:04 ` Martin Sebor
2021-05-17 14:23 ` Stefan Liebler
2021-05-17 15:22 ` 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=051c230f-b7a7-3403-f912-e85ac7bba1b6@gmail.com \
--to=msebor@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=msebor@redhat.com \
--cc=stli@linux.ibm.com \
/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).