Re: [Xen-devel] [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as required

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as 
required"):
> I'd like to note though that in the first two cases we don't alter the
> declared object anyway, but instead a derived one; the declaration
> should not use const for other reasons though. And the 3rd case is
> fiddling with something that has lost its meaning as an object. In fact
> we're about to free the underlying memory. In this case I'd prefer to
> retain the const, but I won't insist as the symbol is non-const right
> now as well.

I think if you do this

  extern const struct blah blah_start[];

it is not safe to cast the const away later.

From C99+TC1+TC2, 6.7.3 5:

  5  If an attempt is made to modify an object defned with a
     const-qualifed type through use of an lvalue with
     non-const-qualifed type, the behavior is undefned. ...

Of course `extern const struct blah blah_start[]' is only a
declaration, not a definition.

But all the declarations/definitions even in different translation
units must be `compatible' (or UB, 6.2.7 2) and for types to be
`compatible' they must be identically qualified (6.7.3 9).

So the compiler authors will say that

  `extern const struct blah blah_start[]'

implies a definition somewhere of an array 

  `extern const struct blah blah_start[ somesize ]

and therefore any accesses `to blah_start' (which in their mind means
any accesses via a pointer whose provenance is blah_start) via
non-const lvalues (even for reading!) is UB.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel