Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> On 06.02.19 at 17:37, <ian.jackson@xxxxxxxxxx> wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> >> - it allows the end-of-whatever symbols to also be handed to
> >>   functions in a type-safe manner
> > 
> > Yes.  However...
> > 
> >>   (we could even have per-instance structure flavors, such that
> >>   unrelated "end" symbols can't be mixed up; for example the type
> >>   could simply be a structure wrapping a field of the original base
> >>   type).
> > 
> > I think this would be difficult to achieve without writing a forbidden
> > pointer comparison in the macro.  It could perhaps be achieved with
> > typeof() if that is available in hypervisor code.
> 
> I'm afraid I don't understand - you want to cast to an integer
> type anyway for doing the comparison.

The usual approach to haking a macro perform an explicit typecheck
(ie, to have the macro check that the types of its arguments are
right) is to have the macro expansion contain a `spurious' comparison
whose result is ignored but which will yield a compile-type type
mismatch if the argument types were wrong.  But this is only legal if
the provenance of the compared pointers is legal for a pointer
comparison.  The bad effects of evaluating an UB expression are not
limited by within-program causality.

> As to typeof() - this being a compiler construct, it is available
> whenever the compiler supports it. We certainly use it
> elsewhere in hypervisor code.

I think then that
   (typeof(X))0 == (typeof(Y))0
is the correct formulation of the type check - because it is legal no
matter the provenance of X and Y.

Ian.

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