From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7B60E3CB51 for ; Mon, 12 Mar 2018 11:38:20 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1520869099; bh=OXb0Hj6qoNJ5YG7sqvaafoKyzZpY5Zowk9dtX0Ksk54=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Wj5BA+fzaO6EIXu+s940aT5M+jXgh0zerSws/rvhit3kiebEbVD5TwGf31dmf5F71 HCE8gDtSQ1O/NH5FD/IgM5gSnPvj1bVlncd7p0+GrU06SW59IG3AsJtckccplcyeSk T0uty0rompqRWijWwYxUoJ68YBjA5V5xhAa0tBt/2wUazLNEfopx8A6D+C0k1BxkY2 x33x8Vhw279kLuV589d3Xb/VMCMNgGcvJs7LQQBEpdO9gW/auTfwRnpLmi17i3EzBo BXHWZsGyXlPS4KNMt/4kp28TjhKDgLESopX4nvdtJ4NyLsoRuq84b2aSCo8jC7xn/I D7/OXHeCMm9Zw== To: Stephen Hemminger Cc: Kevin Darbyshire-Bryant , "cake\@lists.bufferbloat.net" In-Reply-To: <20180312081142.0a9da85c@xeon-e3> References: <20180311091930.86264-1-ldir@darbyshire-bryant.me.uk> <20180311091930.86264-2-ldir@darbyshire-bryant.me.uk> <87bmfujq18.fsf@toke.dk> <5DD63A68-EE32-4A5C-B08E-019FB8CBC9B1@darbyshire-bryant.me.uk> <20180311163423.2e8d63b6@xeon-e3> <874lllk47a.fsf@toke.dk> <20180312081142.0a9da85c@xeon-e3> Date: Mon, 12 Mar 2018 16:38:18 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87sh95b8yd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [PATCH 1/2] cake: print_uint format fixes X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 15:38:20 -0000 Stephen Hemminger writes: >> > Using the =E2=80=98PRId64=E2=80=99 macro won=E2=80=99t work because pr= int_int is using =E2=80=98int=E2=80=99 >> > type internally whereas print_uint uses =E2=80=98uint64_t=E2=80=99 int= ernally. So the >> > format string has to have knowledge of the internal format, *but* >> > there=E2=80=99s no clue of the difference in internal format offered b= y the >> > function name i.e. print_int vs print_uint. >> > >> > I=E2=80=99d 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.=20=20 >>=20 >> Yes, this was basically what I meant by "grating"; I really do agree >> that this API is confusing. >>=20 >> 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? :) >>=20 >> -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