[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |