netdev - Re: [PATCH iproute2] tc: fix warning in q

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHv+uoHM+v3ot4GiL3CJbqUshYkaaumtG6FreHRm5aCDKpbPvg@mail.gmail.com>
Date:   Thu, 28 Nov 2019 10:54:29 +0530
From:   Leslie Monis <lesliemonis@...il.com>
To:     Brian Vazquez <brianvv@...gle.com>
Cc:     Maciej Żenczykowski <maze@...gle.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Brian Vazquez <brianvv.kernel@...il.com>,
        David Ahern <dsahern@...il.com>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH iproute2] tc: fix warning in q_pie.c

On Wed, Nov 27, 2019 at 10:55 PM Brian Vazquez <brianvv@...gle.com> wrote:
>
> On Wed, Nov 27, 2019 at 8:44 AM Maciej Żenczykowski <maze@...gle.com> wrote:
> >
> > > What compiler is this?
> > > The type seems correct already.  The type of double / unsigned long is double.
> > > And the conversion may give different answer.
>
> I don't think this conversion will give a different answer, the
> compiler already change the value from UINT64_MAX to 'UINT64_MAX + 1'
> which is pow of 2 and can be represented precisely in a double.  This
> change is just making that conversion explicit to avoid the warning.

If it helps get rid of the warning on clang, I don't see any issue
with this patch.
The explicit conversion doesn't change the final result at all.
I verified this on GCC 7.4.0 just to be sure.

UINT64_MAX is (2^64 - 1) -- the required value for the calculation.
(double)UINT64_MAX is (2^64) -- the value used by the compiler (in this case)
regardless of whether the conversion is implicit or explicit. This small change
in the required value doesn't affect the precision of the result.


> >
> > Probably some recent version of clang with -Wall.
>
> It's clang 10
>
> >
> > That said, I think the warning/error is correct.
> > UINT64 doesn't fit in double (which is also 64 bits, but includes sign
> > and exponent) - you lose ~13 bits of precision.
> > I'm not aware of a way to (natively) divide a double by a uint64
> > without the loss (not that it really matters since the double doesn't
> > have the requisite precision in the first place).
> >
> > Why do you think the conversion will give a different answer?
> > Isn't this exactly what the compiler will do anyway?
> > It's not like we have long double anymore...