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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Ian Jackson <ian.jackson@xxxxxxxxxx> 03/07/19 3:44 PM >>>
>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.

It looks to me as if we were in agreement then. I was talking about freeing
an object that was const-qualified, not modifying it. The scrubbing of the
memory could be considered part of the freeing, it just ought to occur up
front because of otherwise possible races, and because we have no means
to tell the freeing function to do the scrubbing (in fact I should say "we used
to have no means, as I think right now the memory would be scrubbed
implicitly, so the explicit scrubbing could probably be dropped).


Jan




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