Re: [Xen-devel] [PATCH v9 2/5] xen: introduce SYMBOLS_SUBTRACT and SYMBOLS_COMPARE

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.02.19 at 15:47, <ian.jackson@xxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v9 2/5] xen: introduce 
> SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
>> On 12.02.19 at 13:01, <ian.jackson@xxxxxxxxxx> wrote:
>> > I would particularly welcome the opinion of hypervisor maintainers on
>> > my type safety point, below.
>> 
>> I agree with the requirements you put forward; I think I'd
>> prefer the inline function versions I had suggested (or
>> something similar) over macros though, not the least because
>> they come with "built-in" type safety, rather than grafted one
>> (by adding "pseudo" comparisons).
> 
> I didn't see your proposed inline function, but don't think it can
> work correctly because it won't be type-generic.  Ie, the requirement
> is to use the same `SYMBOLS_DIFFERENCE(p, _foo_end)' for various
> different `struct foo *p'.  p is perhaps of different types in the
> different invocations and the return value needs to have been divided
> by sizeof(*p).

Well, it wasn't a single inline function, but a macro defining an
inline function suitable for a certain (start,end) tuple, at the
same time giving both start and end suitable types which then
also can't be used in the wrong context:
https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg00440.html

> I hate to suggest this now, but as an alternative it would be possible
> to do this:
> 
>  /*
>   *    T *ALTER_PROVENANCE(T *value, T *provenance);
>   *
>   *    Returns a pointer with the value of `value' but the provenance
>   *    of `provenance'; that is, which is considered by the compiler
>   *    to be part of same object as `provenance' and not (necessarily)
>   *    part of the same object as `value'.
>   *
>   *    `value' MUST be within whatever the compiler thinks the size
>   *    of `provenance' is (if the compiler has any way to know the
>   *    size of `provenance').  That is, `value' must be one that can
>   *    legally be constructed by indexing within `provenance'.
>   *
>   *    `value' and `provenance' are evaluated only once each.
>   */
>  #define ALTER_PROVENANCE(value,provenance) ({
>       (void)( typeof((value))0      == (void*)0           );
>       (void)( typeof((provenance))0 == (void*)0           );
>       (void)( typeof((provenance))0 == typeof((value))0   );
>       typeof((provenance)) const alter_provenance__copy = (provenance);
>       (typeof((provenance)))(
>          (char*)(alter_provenance__copy) +
>          ( (uintptr_t)(char*)(value) -
>            (uintptr_t)(char*)(alter_provenance__copy) )
>       )
>  })

I'm having trouble seeing how this would help with the issues
at hand. Would you mind giving an example of how you'd see
this used?

Jan



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