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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v9 2/5] xen: introduce 
SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
> On 12.02.19 at 15:47, <ian.jackson@xxxxxxxxxx> wrote:
> > 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

Ah.  Right.  Yes, that macro looks OK to me.

Although I really think it should use uintpr_t, not `unsigned long'.
IIRC there are special C language spec rules for conversion of
pointers to and from uintptr_t's.  (They are probably applied anyway
for all pointer-to-sufficiently-large-integer conversions but I would
prefer not to bet on that.)

> >  #define ALTER_PROVENANCE(value,provenance) ({
...
> 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?

It may be a red herring.  But you could, perhaps, have your WHATEVER
macro do something like this:

  extern const type pfx##_end__wrong_provenance[];
  static const type *const pfx##_end =
     ALTER_PROVENANCE(pfx##_end__wrong_provenance, pfx##_start);

Ian.

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