From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure
Date: Sat, 10 Mar 2018 15:56:16 +0000 [thread overview]
Message-ID: <EF039398-798B-429A-8F3A-2A64C5C41DF8@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <87po4e24ph.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]
> On 8 Mar 2018, at 11:21, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>>
>> Oh and curiously the bad values go away if you ask for json output
>> it’s much better. Which rather points at a ‘feature’ of the
>> ‘print_string’ behaviour.
>
> Right. Well, the print_* functions are behind several levels of
> pre-processor indirection, so not quite obvious what's going on here.
> Don't really see why they should spit out garbage values, though.
>
>
> Stephen, do you have any ideas?
>
> -Toke
Right, cracked it and it’s horrible!
print_uint is expanded thus: Note the type of value uint64_t
void print_color_uint(enum output_type t, enum color_attr color, const char *key, const char *fmt, uint64_t value);
static inline void print_uint (enum output_type t, const char *key, const char *fmt, uint64_t value)
{ print_color_uint( t, COLOR_NONE, key, fmt, value); };
So far so good.
print_color_uint expands to:
void print_color_uint(enum output_type t, enum color_attr color, const char *key, const char *fmt, uint64_t value)
{
if (((t & PRINT_JSON || t & PRINT_ANY) && _jw))
{ if (!key) jsonw_uint(_jw, value);
else jsonw_uint_field(_jw, key, value);
}
else if ((!_jw && (t & PRINT_FP || t & PRINT_ANY)))
{ color_fprintf( (stdout) , color, fmt, value);
}
};
Again, no issue and we eventually call color_fprintf
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...)
{
int ret = 0;
va_list args;
va_start(args, fmt);
if (!color_is_enabled || attr == COLOR_NONE) {
ret = vfprintf(fp, fmt, args);
goto end;
}
Now, color_printf is a variable argument list function and as such is dependent upon being told the correct size of argument variables in the fmt variable. And that’s our problem, we’re passing a 64bit integer but telling the format string that it’s ‘int’…which I’m guessing can be variable sizes depending on architecture, as can the endianness.
If we instead do (in q_cake.c)
#include <inttypes.h>
print_uint(PRINT_ANY, "min_transport_size", " min/max transport layer size: %10" PRIu64, stnc->min_trnlen);
it works. This needs sanity checking by a clever person.
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-03-10 15:56 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-26 15:08 [Cake] [PATCH] Split tin stats to its own structure to decrease size of tc_cake_xstats Toke Høiland-Jørgensen
2017-12-26 16:28 ` Dave Taht
2017-12-26 16:32 ` Toke Høiland-Jørgensen
2018-01-27 13:05 ` [Cake] [PATCH v2] " Toke Høiland-Jørgensen
2018-02-09 12:58 ` Jonathan Morton
2018-02-09 13:08 ` Toke Høiland-Jørgensen
2018-02-11 17:26 ` [Cake] [PATCH v3] " Toke Høiland-Jørgensen
2018-02-11 17:26 ` [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure Toke Høiland-Jørgensen
2018-03-01 11:02 ` Jonathan Morton
2018-03-01 11:06 ` Sebastian Moeller
2018-03-01 13:59 ` Toke Høiland-Jørgensen
2018-03-05 23:08 ` Jonathan Morton
2018-03-06 11:17 ` Toke Høiland-Jørgensen
2018-03-06 11:46 ` Jonathan Morton
2018-03-06 12:10 ` Sebastian Moeller
2018-03-06 13:08 ` Jonathan Morton
2018-03-06 13:18 ` Sebastian Moeller
2018-03-01 13:59 ` Toke Høiland-Jørgensen
2018-03-04 11:14 ` Toke Høiland-Jørgensen
2018-03-06 15:56 ` Stephen Hemminger
2018-03-06 18:33 ` Toke Høiland-Jørgensen
2018-03-06 21:06 ` Toke Høiland-Jørgensen
2018-03-06 22:31 ` Jonathan Morton
2018-03-07 8:50 ` Toke Høiland-Jørgensen
2018-03-07 10:08 ` Kevin Darbyshire-Bryant
2018-03-07 10:31 ` Toke Høiland-Jørgensen
2018-03-07 10:36 ` Toke Høiland-Jørgensen
2018-03-07 11:08 ` Kevin Darbyshire-Bryant
2018-03-07 11:28 ` Toke Høiland-Jørgensen
2018-03-07 11:59 ` Kevin Darbyshire-Bryant
2018-03-07 12:59 ` Toke Høiland-Jørgensen
2018-03-07 14:21 ` Sebastian Moeller
2018-03-07 14:30 ` Toke Høiland-Jørgensen
2018-03-07 15:25 ` Dave Taht
2018-03-07 15:52 ` Toke Høiland-Jørgensen
2018-03-07 17:26 ` Dave Taht
2018-03-08 22:29 ` Pete Heist
2018-03-07 18:27 ` Kevin Darbyshire-Bryant
2018-03-07 18:35 ` Kevin Darbyshire-Bryant
2018-03-07 18:37 ` Jonathan Morton
2018-03-07 21:34 ` Toke Høiland-Jørgensen
2018-03-08 0:49 ` Jonathan Morton
2018-03-08 7:59 ` Kevin Darbyshire-Bryant
2018-03-08 9:21 ` Kevin Darbyshire-Bryant
2018-03-08 10:32 ` Toke Høiland-Jørgensen
[not found] ` <D8A90884-6DAE-42A6-A680-CD11599DDD97@darbyshire-bryant.me.uk>
2018-03-08 10:57 ` Toke Høiland-Jørgensen
2018-03-08 11:09 ` Kevin Darbyshire-Bryant
2018-03-08 11:14 ` Kevin Darbyshire-Bryant
2018-03-08 11:21 ` Toke Høiland-Jørgensen
2018-03-08 18:32 ` Georgios Amanakis
2018-03-10 15:56 ` Kevin Darbyshire-Bryant [this message]
2018-03-10 16:30 ` Luis E. Garcia
2018-03-07 11:07 ` Kevin Darbyshire-Bryant
2018-03-07 11:19 ` Sebastian Moeller
2018-03-07 11:31 ` Toke Høiland-Jørgensen
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
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EF039398-798B-429A-8F3A-2A64C5C41DF8@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=stephen@networkplumber.org \
--cc=toke@toke.dk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox