https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #14 from Martin Sebor ---
Created attachment 52156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52156&action=edit
Updated patch.
The attached patch is an updated version that fixes a few ICEs. It's not in
the archives becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #13 from Martin Sebor ---
The patch submitted (but not approved) for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #11 from Alexander Cherepanov ---
(In reply to Martin Sebor from comment #10)
> An array is implicitly converted to a pointer;
Sometimes converted, sometimes -- not.
> it's not an lvalue.
Why not? Take for example p[1] that we d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #10 from Martin Sebor ---
An array is implicitly converted to a pointer; it's not an lvalue. But I think
we're splitting hairs. I agree we want a warning for passing past-the-end
pointers to functions that might inadvertently derefe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #9 from Alexander Cherepanov ---
(In reply to Martin Sebor from comment #8)
> In
>
> int i[4];
> int (*p)[4] = &i;
> bar_aux (p[1]);
>
> p[0] points to i and p[1] to (char*)&i + sizeof (i) (which is the same as
> &i[4]).
It s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #8 from Martin Sebor ---
In
int i[4];
int (*p)[4] = &i;
bar_aux (p[1]);
p[0] points to i and p[1] to (char*)&i + sizeof (i) (which is the same as
&i[4]). The latter is a pointer just past the end of i. Evaluating
past-the-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #6 from Vincent Lefèvre ---
bar_aux can be any function. It doesn't need to do any thing. As soon as p[1]
is evaluated, one has undefined behavior, just like in function foo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
CC|
11 matches
Mail list logo
