From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH iproute2 v2] json_print: Fix hidden 64-bit type promotion Date: Wed, 25 Apr 2018 08:12:10 -0700 Message-ID: <20180425081210.41846761@xeon-e3> References: <20180329192220.30101-1-ldir@darbyshire-bryant.me.uk> <20180425143022.6986-1-toke@toke.dk> <20180425075527.680f34fc@xeon-e3> <87bme75o5r.fsf@toke.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netdev@vger.kernel.org, Kevin Darbyshire-Bryant To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Return-path: Received: from mail-pf0-f176.google.com ([209.85.192.176]:39406 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755001AbeDYPMN (ORCPT ); Wed, 25 Apr 2018 11:12:13 -0400 Received: by mail-pf0-f176.google.com with SMTP id z9so15490192pfe.6 for ; Wed, 25 Apr 2018 08:12:13 -0700 (PDT) In-Reply-To: <87bme75o5r.fsf@toke.dk> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 25 Apr 2018 16:57:52 +0200 Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Stephen Hemminger writes: >=20 > > On Wed, 25 Apr 2018 16:30:22 +0200 > > Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > =20 > >> print_uint() will silently promote its variable type to uint64_t, but = there > >> is nothing that ensures that the format string specifier passed along = with > >> it fits (and the function name suggest to pass "%u"). > >>=20 > >> Fix this by changing print_uint() to use a native 'unsigned int' type,= and > >> introduce a separate print_u64() function for printing 64-bit values. = All > >> call sites that were actually printing 64-bit values using print_uint(= ) are > >> converted to use print_u64() instead. > >>=20 > >> Since print_int() was already using native int types, just add a > >> print_s64() to match, but don't convert any call sites. > >>=20 > >> Cc: Kevin Darbyshire-Bryant > >> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen =20 > > > > Yes, this makes sense. Maybe there should be a print_luint for > > consistency. =20 >=20 > I just realised I missed a few call sites, so I'll resend. Should I > call the new function print_luint() instead of print_u64()? Ideally, there would be both functions, and use based on what is being prin= ted. > > Also, I tried (in vain) to make a version that allows GCC to check the > > format string. But it was a struggle and just gave up. =20 >=20 > Yeah, no idea how to do this either... Maybe some magic smatch or multi-line regex it would be possible to find all instances of print_uint, then look at format string of each and se= e if there is a single %u. Some added complexity since some places only print json and d= on't care and pass NULL for format.