https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #15 from Pedro Alves ---
Darn typos. Should be obvious that I meant:
Make it possible to write:
void foo (int, const char *arg) __attribute__ ((__nonnull__ (arg)));
instead of this when foo is a class method:
void foo (int,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #14 from Pedro Alves ---
I had forgotten about this bug, and when I re-read it, the idea of letting
the user refer to the parameter by name crossed my mind.
Like, make it possible to write:
void foo (int, const char *arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
Martin Sebor changed:
What|Removed |Added
Version|unknown |7.1.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #12 from Pedro Alves ---
TBC, the reason I filed this, is because GDB had an incorrect use like that
that survived for a few months:
https://sourceware.org/ml/gdb-patches/2016-11/msg00933.html
until someone compiled GDB with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #11 from Pedro Alves ---
> All the interesting calls here are undefined.
I meant that the one pointed out is undefined even without the nonnull
attribute. I.e., it's not a use case that justifies supporting nonnull(1) on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #10 from Martin Sebor ---
All the interesting calls here are undefined.
The point of the example is to highlight that the nonnull attribute on the
typedef
typedef void F (void*) __attribute__ ((__nonnull__ (1)));
is interpreted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #9 from Pedro Alves ---
> ((A*)0)->g (p)
This is undefined behavior. We forced the world to fix code like that in the
GCC 6 release cycle: https://gcc.gnu.org/gcc-6/changes.html
At best, I'd suggest degrading the error on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #7 from Pedro Alves ---
Funny enough, clang 3.7 (don't have more recent handy), warns in that case,
while it errors on the "this" arg:
nonnull.cc:3:39: error: '__nonnull__' attribute is invalid for the implicit
this argument
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #6 from Pedro Alves ---
I remembered to check what does G++ say when you apply the nonnull to a
non-pointer argument. We get a hard error:
$ /opt/gcc/bin/g++ nonnull.cc -o nonnull -c
nonnull.cc:5:67: error: nonnull argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #5 from Pedro Alves ---
> We certainly should allow __attribute__((nonnull)) on methods, even when that
> > includes nonnull (implicit) also for this.
Yes, agreed, with implicit nonnull with no specified argument.
For the case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #2 from Pedro Alves ---
Yeah, I think it's too late, and it'd cause trouble with compatibility with
clang.
Note that the documentation for the attribute(format)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961
--- Comment #1 from Jonathan Wakely ---
IMHO it would be much, much better if the implicit 'this' wasn't counted and
nonnull(1) referred to 'arg' but maybe it's too late to change that.
15 matches
Mail list logo
