From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Krzysztof Niemiec <krzysztof.niemiec@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>
Subject: Re: [PATCH] drm/i915/gem: Remove unnecessary cast
Date: Fri, 23 Aug 2024 09:37:07 -0400 [thread overview]
Message-ID: <ZsiQgw34xhkgXSP1@intel.com> (raw)
In-Reply-To: <Zr8L4BqjFn67UoLl@ashyti-mobl2.lan>
On Fri, Aug 16, 2024 at 10:20:48AM +0200, Andi Shyti wrote:
> Hi Rodrigo,
>
> On Thu, Aug 15, 2024 at 02:58:25PM -0400, Rodrigo Vivi wrote:
> > On Wed, Aug 14, 2024 at 07:59:47PM +0200, Andi Shyti wrote:
> > > The cast from "long" to "unsigned long" is unnecessary. Remove
> > > it.
> >
> > I don't believe we can be that bold in this statement.
> > Some static analyzer tools might not agree and tell that
> > if the start or end are negative values we could have
> > undefined behavior.
>
> Right, but we do check for negative values before. If we reach
> this point I'm sure this is positive and I'm also sure that a
> positive long fits into an unsigned long.
>
> Maybe I should have been clearer in the commit log.
>
> > > In this case, the variables "start" and "end" are of type long
> > > because they need to account for the possibility of negative
> > > values. However, they are subsequently moved to "unsigned long"
> > > since addresses are typically handled as unsigned values.
> >
> > right, but the static analyzer tools won't agree and complain
> > and people will start try to add this back.
> >
> > Do we really need this patch?
>
> It's a cleanup, like removing trailing spaces, none of them is
> really needed :-)
>
> Trivial removals of unnecessary casts are normally done around
> the kernel, but, of course we can drop this patch.
My only concern was to remove and then we start having people
trying to add it back again because some static analyzer tool
complained about the undefined behavior.
But if you are sure that this won't happen let's go with it.
Please just rephrase the commit message.
>
> Thanks,
> Andi
next prev parent reply other threads:[~2024-08-23 13:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 17:59 [PATCH] drm/i915/gem: Remove unnecessary cast Andi Shyti
2024-08-14 18:51 ` ✗ Fi.CI.BAT: failure for " Patchwork
2024-08-14 21:41 ` ✓ Fi.CI.BAT: success for drm/i915/gem: Remove unnecessary cast (rev2) Patchwork
2024-08-15 18:58 ` [PATCH] drm/i915/gem: Remove unnecessary cast Rodrigo Vivi
2024-08-16 8:20 ` Andi Shyti
2024-08-23 13:37 ` Rodrigo Vivi [this message]
2024-08-16 5:15 ` ✗ Fi.CI.IGT: failure for drm/i915/gem: Remove unnecessary cast (rev2) Patchwork
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=ZsiQgw34xhkgXSP1@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=krzysztof.niemiec@intel.com \
/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