Re: [PATCH v1 02/48] tools headers: Silence -Wshorten-64-to-32 warnings

[Ian Rogers]

On Thu, Apr 3, 2025 at 11:18 AM Yury Norov <yury.norov@xxxxxxxxx> wrote:
>
> On Thu, Apr 03, 2025 at 11:12:30AM -0700, Ian Rogers wrote:
> > On Thu, Apr 3, 2025 at 8:45 AM Ian Rogers <irogers@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Apr 3, 2025 at 8:23 AM Yury Norov <yury.norov@xxxxxxxxx> wrote:
> > > >
> > > > On Thu, Apr 03, 2025 at 07:52:45AM -0700, Ian Rogers wrote:
> > > > > On Thu, Apr 3, 2025 at 7:26 AM Yury Norov <yury.norov@xxxxxxxxx> wrote:
> > > > > >
> > > > > > On Thu, Apr 03, 2025 at 10:08:39AM -0400, Yury Norov wrote:
> > > > > > > On Tue, Apr 01, 2025 at 11:23:00AM -0700, Ian Rogers wrote:
> > > > > > > > The clang warning -Wshorten-64-to-32 can be useful to catch
> > > > > > > > inadvertent truncation. In some instances this truncation can lead to
> > > > > > > > changing the sign of a result, for example, truncation to return an
> > > > > > > > int to fit a sort routine. Silence the warning by making the implicit
> > > > > > > > truncation explicit.
> > > > > > > >
> > > > > > > > Signed-off-by: Ian Rogers <irogers@xxxxxxxxxx>
> > > > > >
> > > > > > I'm the first person in the To list, but only a couple patches in the
> > > > > > series are related to my area. If you want to move it with me, can you
> > > > > > send bitmaps, bitfields etc. separately?
> > > > >
> > > > > Hi Yury,
> > > > >
> > > > > If you think it is worthwhile. I did the series to see how prevalent a
> > > > > bug was in perf's code - inspired by Leo Yan fixing an instance of it.
> > > > > I would prefer not to be on the hook for all the kernel warnings :-)
> > > > > Perhaps casts to avoid changing bitmap_weight's type. Unfortunately to
> > > > > get to where the perf issues were I needed to clean up header files.
> > > > > In the bitmap cases the change is just to make implicit casts explicit
> > > > > and I don't know how much value you see in that.
> > > >
> > > > Your changes  are technically correct (except for non-synced kernel and
> > > > tools), make the code cleaner, at least to me, and address pretty valid
> > > > compiler's concerns. To me, it's worth to apply.
> > >
> > > Ok cool. I'll make a separate patch series for them. Sorry for giving
> > > you such a long patch series with limited signal to noise.
> >
> > Posted here:
> > https://lore.kernel.org/lkml/20250403165702.396388-1-irogers@xxxxxxxxxx/
>
> Yep, I see. Let's wait for a while for any feedback? If all OK, I'll
> move it with my branch.

Great, thanks! I only did the kernel version and not the tools version
as the tools versions are already quite out-of-sync. It makes sense to
get the kernel versions good and then pull them into tools.

Thanks,
Ian