diff options
author | Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> | 2018-05-06 14:20:01 +0000 |
---|---|---|
committer | John Crispin <john@phrozen.org> | 2018-05-07 08:09:05 +0200 |
commit | ad5af37ca793b8c065d40a10054fd24b88705180 (patch) | |
tree | e6b5953655d4e82ed9c1cbde3dfb86424c104d88 /tools/make-ext4fs/patches/100-add-ldflags.patch | |
parent | 53c474abbdfef8eb3499e2d10c9ad491788b8a72 (diff) | |
download | upstream-ad5af37ca793b8c065d40a10054fd24b88705180.tar.gz upstream-ad5af37ca793b8c065d40a10054fd24b88705180.tar.bz2 upstream-ad5af37ca793b8c065d40a10054fd24b88705180.zip |
iproute2: backport json_print-fix-hidden-64-bit-type-promotion
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
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.
Fixes wonkyness in some stats from some qdiscs under tc
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Diffstat (limited to 'tools/make-ext4fs/patches/100-add-ldflags.patch')
0 files changed, 0 insertions, 0 deletions