Re: [PATCH] verbs: fix compilation warning with C++20

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 9, 2023 at 6:18 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> On Fri, Jun 09, 2023 at 06:15:44PM +0200, Daniel Vacek wrote:
> > On Fri, Jun 9, 2023 at 6:01 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> > > On Fri, Jun 09, 2023 at 05:31:47PM +0200, Daniel Vacek wrote:
> > > > Our customer reported the below warning whe using Clang v16.0.4 and C++20,
> > > > on a code that includes the header "/usr/include/infiniband/verbs.h":
> > > >
> > > > error: bitwise operation between different enumeration types ('ibv_access_flags' and
> > > > 'ib_uverbs_access_flags') is deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
> > > >                 mem->mr = ibv_reg_mr(dev->pd, (void*)start, len, IBV_ACCESS_LOCAL_WRITE);
> > > >                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > /usr/include/infiniband/verbs.h:2514:19: note: expanded from macro 'ibv_reg_mr'
> > > >                              ((access) & IBV_ACCESS_OPTIONAL_RANGE) == 0))
> > > >                               ~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > 1 error generated.
> > > >
> > > > According to the article "Clang 11 warning: Bitwise operation between different
> > > > enumeration types is deprecated":
> > > >
> > > > C++20's P1120R0 deprecated bitwise operations between different enums. Such code is
> > > > likely to become ill-formed in C++23. Clang 11 warns about such cases. It should be fixed.
> > >
> > > There should be a cast to an integer in the macro, we can't know what
> > > the user will pass in there and it may not be that enum.
> >
> > Hmm, if the user passes a definition from the header files at least we
> > should be consistent I'd say, which is this case. No one was passing
> > any custom values here.
> > If you cast to an integer here you may start silently hiding possible
> > errors. If the user passes any custom value, IMO, it's his
> > responsibility to make it right.
>
> The signature of the API is to accept an int, we cannot demand any
> more of that from the user. The macro wiped out the type cast to an
> int, it should put it back.

Oh, I see. In that case shall we still keep this patch or just do the cast?

--nX

> Jason
>





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux