https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #11 from Alexander Cherepanov <ch3root at openwall dot com> ---
(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 discussed. It's equivalent to *(p+1) and
the unary * operator is explicitly documented to yield an lvalue (C11,
6.5.3.2p4):
"If the operand points to a function, the result is a function designator; if
it points to an object, the result is an lvalue designating the object."
> But I
> think we're splitting hairs. I agree we want a warning for passing
> past-the-end pointers to functions that might inadvertently dereference it;
> I plan to implement it for GCC 11.
This is something more general and I'm not sure we want such a warning. You are
right that passing a past-the-end pointers to functions perfectly legal so
there would be false alarms. I cannot readily assess whether it's worth it.
OTOH the specific construction that started this PR is not legal and should
always give a warning, whether it's passed to an unknown function, printed
without additional dereferences or used in a computation.
> The reference in
>
> int a[1][4];
> printf("%p\n", (void *)&a[1][1]);
>
> is of course undefined, but when the warning sees the address-of operator it
> allows off-by-one indices. That's necessary only for the rightmost index
> but not otherwise. The missing warning here is the subject of pr84079. I
> have a simple fix that handles this case.
Great, here we agree. But does it cover &a[1][0]?
