> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Wednesday, 24 August 2022 09.39
>
> 24/08/2022 08:50, David Marchand:
> > On Fri, Jul 29, 2022 at 3:22 PM David Marchand
> > <david.march...@redhat.com> wrote:
> > >
> > > On Fri, Jul 29, 2022 at 11:59 AM Bruce Richardson
> > > <bruce.richard...@intel.com> wrote:
> > > > > > Personally, I really don't like these macros at all. I think
> having the
> > > > > > check explicitly in the code would be far more readable, and
> would only be
> > > > > > one line of code longer than the macro call. Is there some
> private header
> > > > > > file we could move these to instead of rte_common.h so we can
> drop their
> > > > > > use in future if we decide to?
> > > > >
> > > > > I don't like them either.
> > > > > Not sure where to put them though...
> > > > >
> > > > > My "grep-all" shows no user in the projects consuming DPDK I
> track.
> > > > > We could mark those macros deprecated, fix our code and drop
> them later.
> > > > >
> > > > +1 to that.
> > > > Can they be marked as deprecated as part of the move perhaps
> (assuming we
> > > > get agreement to kill them?)
> >
> > Let's see if techboard members have an opinion.
>
> These macros have no added value for an external user.
> I think it is OK to mark them deprecated and plan for a future removal.
+1 from a community member :-)
>
> Copy of the code for the context:
>
> /** Macros to check for invalid function pointers. */
> #define RTE_FUNC_PTR_OR_ERR_RET(func, retval) do { \
> if ((func) == NULL) \
> return retval; \
> } while (0)
>
> #define RTE_FUNC_PTR_OR_RET(func) do { \
> if ((func) == NULL) \
> return; \
> } while (0)
>
>
>
