Stephen Hemminger <[email protected]> writes: >> > 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. >> >> Yes, this was basically what I meant by "grating"; I really do agree >> that this API is confusing. >> >> Stephen, would you accept patches to fix the API (to add >> print_{u,}int64() variants and turn print_uint() into native-int size)? >> Or should we stick with the API currently there and live with the >> inconsistency? :) >> >> -Toke > > I agree print_int should take int, print_uint should take unsigned > int, and there should be print_u64 (and print_u32, print_u8)
Cool. Kevin, do you feel like submitting a patch? :) -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
