> On 12 Mar 2018, at 15:38, Toke Høiland-Jørgensen <[email protected]> wrote: > > 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
I’m in full on $paidwork broadcast sound supervisor mode for the next 4 days, so it won’t be done in a screaming rush. Talk about patch feature creep ;-) 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
