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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Jun 09, 2023 at 06:29:55PM +0200, Daniel Vacek wrote:
> On Fri, Jun 9, 2023 at 6:18 PM Jason Gunthorpe <jgg@ziepe.ca> 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@ziepe.ca> 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?

Just do the cast

Jason