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 C858E3CB5D for ; Mon, 12 Mar 2018 05:56:11 -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=1520848570; bh=1aPKJBqeBdVv/WhrjOv6v1rfVc68i4LBdv7pxumFPJk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C4Ahqfyjs699MjMmwQQJTKWouycB42syfDr8HmDWFNrIQpHv1DpkqGiDQPS6axU0/ IwttMsn6g86aISrWJNF7GIUc+2FGbZd1klnOZgObKMuygzfWtaK1psIzYkHo2/mknJ jiJrGnIGtl4Qa77RtlWscNCb+tZa223/xOAEhupc+QqX3JCMAlkqRjed1cWhohfqW2 25s5mq74fL8NcHPPFgcu7WmDaJROyBxlikqo255Z/q0YTAnpq5TogmdNUJsLwS52l+ gWX+eec+5cYRdBgkdtD4XAfySER53Vyv36/r0mxgZnbizgqfa6lrgSUqPuQGGxDwkw r+XM1e05pkXNQ== To: Kevin Darbyshire-Bryant , Stephen Hemminger Cc: "cake\@lists.bufferbloat.net" In-Reply-To: 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> Date: Mon, 12 Mar 2018 10:56:09 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874lllk47a.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 09:56:12 -0000 Kevin Darbyshire-Bryant writes: >> On 11 Mar 2018, at 23:34, Stephen Hemminger = wrote: >>=20 >> On Sun, 11 Mar 2018 22:10:51 +0000 >> Kevin Darbyshire-Bryant wrote: >>=20 >>> negative? >>>=20 >>> Tried it, and you=E2=80=99d sort of guess wrong. I=E2=80=99ll write it = up tomorrow >>> =E2=80=98properly=E2=80=99 but =E2=80=98int=E2=80=99 is int length wher= eas uint is uint64 length. On >>> big endian it goes wrong. >>>=20 >>> Anyway, glad you=E2=80=99ve tested on something little endian. I=E2=80= =99ll try to >>> submit a patch upstream as requested=E2=80=A6very busy over next 3 days >>> doing $dayjob so may take a little while. Thanks for boosting >>> confidence that I=E2=80=99ve not broken it on architectures it used to = work >>> on :-) >>=20 >> print_uint should be unsigned only. >>=20 >> 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. Yeah, this is fixed in the tc-adv git repo now :) > Using the =E2=80=98PRId64=E2=80=99 macro won=E2=80=99t work because print= _int is using =E2=80=98int=E2=80=99 > type internally whereas print_uint uses =E2=80=98uint64_t=E2=80=99 intern= ally. 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 by t= he > 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. 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