On Wed, 25 Apr 2018 16:57:52 +0200 Toke Høiland-Jørgensen <t...@toke.dk> wrote:
> Stephen Hemminger <step...@networkplumber.org> writes: > > > On Wed, 25 Apr 2018 16:30:22 +0200 > > Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > > >> 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"). > >> > >> 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. > >> > >> Since print_int() was already using native int types, just add a > >> print_s64() to match, but don't convert any call sites. > >> > >> Cc: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk> > >> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk> > > > > Yes, this makes sense. Maybe there should be a print_luint for > > consistency. > > 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 printed. > > 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. > > 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 see if there is a single %u. Some added complexity since some places only print json and don't care and pass NULL for format.
