public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: gcc-patches@gcc.gnu.org
Cc: libc-alpha@sourceware.org, Martin Sebor <msebor@redhat.com>
Subject: Invalid -Wstringop-overread warning for valid POSIX constructs
Date: Thu, 04 Nov 2021 08:03:33 +0100	[thread overview]
Message-ID: <87k0hojtbu.fsf@oldenburg.str.redhat.com> (raw)

This code:

#include <pthread.h>
#include <sys/mman.h>

void
f (pthread_key_t key)
{
  pthread_setspecific (key, MAP_FAILED);
}

Results in a warning:

t.c: In function ‘f’:
t.c:7:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Wstringop-overread]
    7 |   pthread_setspecific (key, MAP_FAILED);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from t.c:1:
/usr/include/pthread.h:1308:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
 1308 | extern int pthread_setspecific (pthread_key_t __key,
      |            ^~~~~~~~~~~~~~~~~~~


This also results in the same warning, for different reasons:

#include <pthread.h>

extern int x[1];

void
f (pthread_key_t key)
{
  pthread_setspecific (key, &x[1]);
}

t.c: In function ‘f’:
t.c:8:3: warning: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Wstringop-overread]
    8 |   pthread_setspecific (key, &x[1]);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:3:12: note: at offset 4 into source object ‘x’ of size 4
    3 | extern int x[1];
      |            ^
In file included from t.c:1:
/usr/include/pthread.h:1308:12: note: in a call to function ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
 1308 | extern int pthread_setspecific (pthread_key_t __key,
      |            ^~~~~~~~~~~~~~~~~~~

The original argument justifying this warning was that passing
non-pointer constants is invalid.  But MAP_FAILED is a valid POSIX
pointer constant, so it is allowed here as well.  And the second example
shows that the warning also fires for completely valid pointers.  So the
none access attribute is clearly not correct here.  (“none” requires
that the pointer is valid, there just aren't any accesses to the object
it points to, but the object must exist.  Apparently, this is what the
kernel expects for its use of the annotation.)

The root of the problem is the const void * pointer argument.  Without
the access attribute, we warn for other examples:

typedef unsigned int pthread_key_t;
int pthread_setspecific (pthread_key_t __key, const void *);

void
f (pthread_key_t key)
{
  int x;
  pthread_setspecific (key, &x);
}

t.c: In function ‘f’:
t.c:10:3: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized]
   10 |   pthread_setspecific (key, &x);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:4:5: note: by argument 2 of type ‘const void *’ to ‘pthread_setspecific’ declared here
    4 | int pthread_setspecific (pthread_key_t __key, const void *);
      |     ^~~~~~~~~~~~~~~~~~~
t.c:9:7: note: ‘x’ declared here
    9 |   int x;
      |       ^

This is why we added the none access attribute, but this leads to the
other problem.

We could change glibc to use a different attribute (preferable one that
we can probe using __has_attribute) if one were to become available, and
backport that.  But so far, I see nothing on the GCC side, and
GCC PR 102329 seems to have stalled.

Thanks,
Florian


             reply	other threads:[~2021-11-04  7:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04  7:03 Florian Weimer [this message]
2021-11-04 15:32 ` Martin Sebor
2021-11-04 15:51   ` Florian Weimer

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=87k0hojtbu.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=msebor@redhat.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).