Re: [PATCH v2 bpf 07/11] samples/bpf: fix uin64_t format literals

From: David Laight <redacted>
Date: Thu, 21 Apr 2022 07:46:05 +0000

From: Alexander Lobakin

quoted

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