From: Stephen Hemminger <stephen@networkplumber.org>
To: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH iproute2-next] json_print: fix print_uint with helper type extensions
Date: Thu, 29 Mar 2018 14:03:50 -0700 [thread overview]
Message-ID: <20180329140350.30a61953@xeon-e3> (raw)
In-Reply-To: <20180329193210.30415-1-ldir@darbyshire-bryant.me.uk>
On Thu, 29 Mar 2018 20:32:10 +0100
Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> wrote:
> Introduce print helper functions for int, uint, explicit int32, uint32,
> int64 & uint64.
>
> print_int used 'int' type internally, whereas print_uint used 'uint64_t'
>
> These helper functions eventually call vfprintf(fp, fmt, args) which is
> a variable argument list function and is dependent upon 'fmt' containing
> correct information about the length of the passed arguments.
>
> Unfortunately print_int v print_uint offered no clue to the programmer
> that internally passed ints to print_uint were being promoted to 64bits,
> thus the format passed in 'fmt' string vs the actual passed integer
> could be different lengths. This is even more interesting on big endian
> architectures where 'vfprintf' would be looking in the middle of an
> int64 type.
>
> print_u/int now stick with native int size. print_u/int32 & print
> u/int64 functions offer explicit integer sizes.
>
> To portably use these formats you should use the relevant PRIdN or PRIuN
> formats as defined in inttypes.h
>
> e.g.
>
> print_uint64(PRINT_ANY, "refcnt", "refcnt %" PRIu64 " ", t->tcm_info)
>
> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
> ---
> include/json_print.h | 6 +++++-
> lib/json_print.c | 6 +++++-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/json_print.h b/include/json_print.h
> index 2ca7830a..fb62b142 100644
> --- a/include/json_print.h
> +++ b/include/json_print.h
> @@ -56,10 +56,14 @@ void close_json_array(enum output_type type, const char *delim);
> print_color_##type_name(t, COLOR_NONE, key, fmt, value); \
> }
> _PRINT_FUNC(int, int);
> +_PRINT_FUNC(uint, unsigned int);
> _PRINT_FUNC(bool, bool);
> _PRINT_FUNC(null, const char*);
> _PRINT_FUNC(string, const char*);
> -_PRINT_FUNC(uint, uint64_t);
> +_PRINT_FUNC(int32, int32_t);
> +_PRINT_FUNC(uint32, uint32_t);
> +_PRINT_FUNC(int64, int64_t);
> +_PRINT_FUNC(uint64, uint64_t);
> _PRINT_FUNC(hu, unsigned short);
> _PRINT_FUNC(hex, unsigned int);
> _PRINT_FUNC(0xhex, unsigned int);
> diff --git a/lib/json_print.c b/lib/json_print.c
> index bda72933..1194a6ec 100644
> --- a/lib/json_print.c
> +++ b/lib/json_print.c
> @@ -116,8 +116,12 @@ void close_json_array(enum output_type type, const char *str)
> } \
> }
> _PRINT_FUNC(int, int);
> +_PRINT_FUNC(uint, unsigned int);
> _PRINT_FUNC(hu, unsigned short);
> -_PRINT_FUNC(uint, uint64_t);
> +_PRINT_FUNC(int32, int32_t);
> +_PRINT_FUNC(uint32, uint32_t);
> +_PRINT_FUNC(int64, int64_t);
> +_PRINT_FUNC(uint64, uint64_t);
> _PRINT_FUNC(lluint, unsigned long long int);
> _PRINT_FUNC(float, double);
> #undef _PRINT_FUNC
You sent patches to both trees. That is not the correct protocol.
Choose one, get it reviewed. iproute2-next will get merged from master (in fact
dave should be doing it regularly).
next prev parent reply other threads:[~2018-03-29 21:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 19:32 [PATCH iproute2-next] json_print: fix print_uint with helper type extensions Kevin Darbyshire-Bryant
2018-03-29 21:03 ` Stephen Hemminger [this message]
2018-03-29 21:08 ` Kevin Darbyshire-Bryant
2018-03-30 14:57 ` David Ahern
2018-03-30 15:02 ` Kevin Darbyshire-Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180329140350.30a61953@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=ldir@darbyshire-bryant.me.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.