This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: nightly test result of systemtap in ppc64
- From: Roland McGrath <roland at redhat dot com>
- To: Hien Nguyen <hien at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Mon, 10 Apr 2006 13:28:49 -0700 (PDT)
- Subject: Re: nightly test result of systemtap in ppc64
> powerpc does not like
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", l->__tmp18,
> l->__tmp21, l->__tmp22);
> but likes this
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6lld %s(%lld):", (long
> long)l->__tmp18, l->__tmp21, (long long)l->__tmp22);
> or this
> snprintf (l->__tmp23, MAXSTRINGLEN, "%6ld %s(%ld):", l->__tmp18,
> l->__tmp21, l->__tmp22);
>
> could it be a compiler bug?
It's not a bug. The types like int64_t might correspond to long long or to
long, depending on the processor. On 64-bit machines, long is 64 bits and
so it is used instead of long long in the definition. The warning tells
you when the source language types don't match, not when their layouts
actually differ (that way you get something useful for portability to
machines where the sizes and layouts may be different from what you are
compiling with right now).
In ISO C99, you use the macros from <inttypes.h> to go with the types,
i.e. PRId64. The kernel does not define those macros. I think the easiest
thing here is to just use "long long" in place of int64_t in kernel code.
In the far future, that may one day mean 128 bits or something, but then
lots of kernel code will have to be cleaned up anyway.
Thanks,
Roland