On 07/04/2011 01:10 AM, Matthias Bolte wrote: >> +/* The double cast is necessary to silence gcc warnings; any pointer >> + * can safely go to intptr_t and back to void *, which collapses >> + * arrays into pointers; while any integer can be widened to intptr_t >> + * then cast to void *. */ >> +# define VIR_ADD_CAST(a) ((void *)(intptr_t)(a)) > > Is this really true? What about a long long value (64bit) on a 32bit > platform? intptr_t and void* are only 32bit on a 32bit platform, > aren't they? Hmm, interesting point. On the other hand, can PROBE even operate on 'long long', or does it only operate on 'size_t'/'void *' operands? That is, the whole point of system tap is to inject probe points that make it easier to run system tap on a binary, where each use of the PROBE() macro injects enough code to pass arbitrary bits through the kernel so that a running systemtap can then reinterpret those bits with the appropriate type according to the probe point that systemtap is tracing. I also discovered that my cast is not always gcc silent - gcc insists on warning for (intptr_t)(func()) for any func that returns a pointer instead of an integer; but in those cases, the use of an intermediate variable works around the warning. It is really annoying that gcc does not provide any counterpart to __typeof__ that would let you produce the decayed type of an input argument - life would be much simpler if there were a way to decay an expression of type 'char[100]' into an intermediate variable of type 'char *'. At any rate, since none of our current uses of PROBE() pass either 'long long' or a function call that returns 'char *', we aren't adding any additional problems by accepting this patch, but we also might be adding a latent bug that would be hard to diagnose in the future. I'm not sure whether we want to apply this patch, or just require systemtap 1.3 or newer as a prerequisite for compiling libvirt. Thoughts? How prevalent are systemtap 1.2 installations? -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list