[PATCH] c/67882 - improve -Warray-bounds for invalid offsetof
Joseph Myers
joseph@codesourcery.com
Tue Nov 10 00:02:00 GMT 2015
On Sat, 7 Nov 2015, Segher Boessenkool wrote:
> > The last one is certainly invalid. The one before is arguably invalid as
> > well (in the unary '&' equivalent, &a5_7[5][0] which is equivalent to
> > a5_7[5] + 0, the questionable operation is implicit conversion of a5_7[5]
> > from array to pointer - an array expression gets converted to an
> > expression "that points to the initial element of the array object", but
> > there is no array object a5_7[5] here).
>
> C11, 6.5.2.1/3:
> Successive subscript operators designate an element of a
> multidimensional array object. If E is an n-dimensional array (n >= 2)
> with dimensions i x j x . . . x k, then E (used as other than an lvalue)
> is converted to a pointer to an (n - 1)-dimensional array with
> dimensions j x . . . x k. If the unary * operator is applied to this
> pointer explicitly, or implicitly as a result of subscripting, the
> result is the referenced (n - 1)-dimensional array, which itself is
> converted into a pointer if used as other than an lvalue. It follows
> from this that arrays are stored in row-major order (last subscript
> varies fastest).
>
> As far as I see, a5_7[5] here is never treated as an array, just as a
> pointer, and &a5_7[5][0] is valid.
As usual, based on taking the address, not offsetof where there's the open
question of whether the C standard actually requires support for anything
other than a single element name there:
a5_7[5] is an expression of array type. The only way for it to be treated
as a pointer is for it to be converted implicitly to pointer type. That
implicit conversion is what I think is problematic.
Only once the implicit conversion has taken place do the special rules
about &A[B] meaning A + B take effect. But since the problem I see is
with the conversion of A to a pointer, you still have undefined behavior.
The paragraph you quote seems to not to add anything to the semantics
defined elsewhere in the standard; it's purely descriptive of some
consequences of those semantics.
Whether we wish to be more permissive about some such cases (depending on
-Warray-bounds=N) is a pragmatic matter depending on the extent to which
they are used in practice.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Gcc-patches
mailing list