> On 11 Mar 2018, at 23:34, Stephen Hemminger <[email protected]> > wrote: > > On Sun, 11 Mar 2018 22:10:51 +0000 > Kevin Darbyshire-Bryant <[email protected]> wrote: > >> negative? >> >> Tried it, and you’d sort of guess wrong. I’ll write it up tomorrow >> ‘properly’ but ‘int’ is int length whereas uint is uint64 length. On big >> endian it goes wrong. >> >> Anyway, glad you’ve tested on something little endian. I’ll try to submit a >> patch upstream as requested…very busy over next 3 days doing $dayjob so may >> take a little while. Thanks for boosting confidence that I’ve not broken it >> on architectures it used to work on :-) > > print_uint should be unsigned only. > > When printing json your version won't work with negative values.
Yes, it should be: print_int(PRINT_ANY, "overhead", "overhead %d ", overhead); - certainly that works on my 32 bit big endian box. Using the ‘PRId64’ macro won’t work because print_int is using ‘int’ type internally whereas print_uint uses ‘uint64_t’ internally. So the format string has to have knowledge of the internal format, *but* there’s no clue of the difference in internal format offered by the function name i.e. print_int vs print_uint. I’d argue it makes more sense to have: print_int/print_uint as the native int length, that hopefully match up with %u & %d and then have print_int64/print_uint64 where use of formats PRId64 & PRIu64 is advised. But I’m definitely arguing from a position of lack of knowledge/experience. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
