Messages in this thread | | | Date | Thu, 21 Apr 2022 22:55:08 +0000 | From | Alexander Lobakin <> | Subject | Re: [PATCH v2 bpf 07/11] samples/bpf: fix uin64_t format literals |
| |
From: David Laight <David.Laight@ACULAB.COM> Date: Thu, 21 Apr 2022 07:46:05 +0000
> From: Alexander Lobakin > > Sent: 21 April 2022 01:40 > > > > There's a couple places where uin64_t is being passed as an %lu > > format argument. That type is defined as unsigned long on 64-bit > > systems and as unsigned long long on 32-bit, so neither %lu nor > > %llu are not universal. > > One of the options is %PRIu64, but since it's always 8-byte long, > > just cast it to the _proper_ __u64 and print as %llu. > > Is __u64 guaranteed to be 'unsigned long long' ? No reason why it should be. > I think you need to cast to (unsigned long long).
__u64 can be unsigned long only if an architecture uses int-l64.h instead of int-ll64.h. This is currently possible for Alpha and PPC64 when __SANE_USERSPACE_TYPES__ is not defined -- I guess you know what that flag does. I messed up a bit and didn't notice that samples/bpf/Makefile defines this flag only for MIPS. IMO it should be defined in here unconditionally, but I guess it's out of bpf-fixes scope, so I'll go with unsigned long long in v3 (got to resend with no PGP crap anyway lol).
> > David
--- 8< ---
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
Thanks, Al
| |