[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k0u1no8g.fsf@nvidia.com>
Date: Tue, 01 Dec 2020 23:41:29 +0100
From: Petr Machata <me@...chata.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Petr Machata <me@...chata.org>, netdev@...r.kernel.org,
dsahern@...il.com, Po.Liu@....com, toke@...e.dk,
dave.taht@...il.com, edumazet@...gle.com, tahiliani@...k.edu.in,
leon@...nel.org
Subject: Re: [PATCH iproute2-next 3/6] lib: Move sprint_size() from tc here, add print_size()
Stephen Hemminger <stephen@...workplumber.org> writes:
> On Mon, 30 Nov 2020 23:59:39 +0100
> Petr Machata <me@...chata.org> wrote:
>
>> +char *sprint_size(__u32 sz, char *buf)
>> +{
>> + size_t len = SPRINT_BSIZE - 1;
>> + double tmp = sz;
>> +
>> + if (sz >= 1024*1024 && fabs(1024*1024*rint(tmp/(1024*1024)) - sz) < 1024)
>> + snprintf(buf, len, "%gMb", rint(tmp/(1024*1024)));
>> + else if (sz >= 1024 && fabs(1024*rint(tmp/1024) - sz) < 16)
>> + snprintf(buf, len, "%gKb", rint(tmp/1024));
>> + else
>> + snprintf(buf, len, "%ub", sz);
>> +
>> + return buf;
>> +}
>
> Add some whitespace here and maybe some constants like mb and kb?
Sure.
> Also, instead of magic SPRINT_BSIZE, why not take a len param (and
> name it snprint_size)?
Because keeping the interface like this makes it possible to reuse the
macroized bits in q_cake. I feel like the three current users are
auditable enough that the implied length is not a big deal. And no new
users should pop up, as the comment at the function makes clear.
> Yes when you copy/paste code it is good time to get it back to current
> style standards.
Powered by blists - more mailing lists