All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leslie Monis <lesliemonis@gmail.com>
To: Brian Vazquez <brianvv@google.com>
Cc: "Maciej Żenczykowski" <maze@google.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Brian Vazquez" <brianvv.kernel@gmail.com>,
	"David Ahern" <dsahern@gmail.com>,
	"Mahesh Bandewar" <maheshb@google.com>,
	"Linux NetDev" <netdev@vger.kernel.org>
Subject: Re: [PATCH iproute2] tc: fix warning in q_pie.c
Date: Thu, 28 Nov 2019 10:54:29 +0530	[thread overview]
Message-ID: <CAHv+uoHM+v3ot4GiL3CJbqUshYkaaumtG6FreHRm5aCDKpbPvg@mail.gmail.com> (raw)
In-Reply-To: <CAMzD94R4AqjgtqxgpnZ67H6GvQzin1idxj8OjMmOfmruEc9_CQ@mail.gmail.com>

On Wed, Nov 27, 2019 at 10:55 PM Brian Vazquez <brianvv@google.com> wrote:
>
> On Wed, Nov 27, 2019 at 8:44 AM Maciej Żenczykowski <maze@google.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...

  reply	other threads:[~2019-11-28  5:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  5:20 [PATCH iproute2] tc: fix warning in q_pie.c Brian Vazquez
2019-11-27 16:26 ` Stephen Hemminger
2019-11-27 16:44   ` Maciej Żenczykowski
2019-11-27 17:25     ` Brian Vazquez
2019-11-28  5:24       ` Leslie Monis [this message]
2019-12-04 19:37 ` Stephen Hemminger

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=CAHv+uoHM+v3ot4GiL3CJbqUshYkaaumtG6FreHRm5aCDKpbPvg@mail.gmail.com \
    --to=lesliemonis@gmail.com \
    --cc=brianvv.kernel@gmail.com \
    --cc=brianvv@google.com \
    --cc=dsahern@gmail.com \
    --cc=maheshb@google.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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.