Re: [dpdk-dev] [dpdk-techboard] [PATCH v6 2/8] eal: fix error attribute use for clang

[Thomas Monjalon <thomas@monjalon.net>]

29/01/2021 09:35, David Marchand:
> On Thu, Jan 28, 2021 at 6:36 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> > > > > > We will never know about those compilers behavior, like how we caught
> > > > > > the clang issue and found an alternative.
> > > > > >
> > > > >
> > > > > So I understand, but I'm still concerned about breaking something that was
> > > > > previously working. It's one thing a DPDK developer catching issues with
> > > > > clang, quite another a user catching it when trying to build their own
> > > > > application.
> > > > >
> > > > > We probably need some other opinions on this one.
> > > > >
> > > > Adding Tech-board to see if we can get some more thoughts on this before I do
> > > > another revision of this set.
> > >
> > > What are the alternatives?
> > >
> >
> > The basic problem is what to do when a compiler is used which does not support
> > the required macros to flag an error for use of an internal-only function.
> > For example, we discovered this because clang does not support the #error
> > macro.
> 
> *attribute*
> 
> >
> > In those cases, as I see it, we really have two choices:
> >
> > 1 ignore flagging the error and silently allow possible use of the internal
> >   function.
> > 2 have the compiler flag an error for an unknown macro
> >
> > The problem that I have with #2 is that without knowing the macro, the
> > compiler will likely error out any time a user app includes any header with
> > an internal function, even if the function is unused.
> >
> > On the other hand, the likelihood of impact if we choose #2 and do error out is
> > quite small, since modern clang versions will support the modern macro
> > checks we need, and just about any gcc versions we care about are going to
> > support #error.

If there are very small chances of hitting the issue, it looks acceptable.
But I don't really like risking issues with not tested compilers.

> > For #1, the downside is that we will miss error checks on some older
> > versions of gcc e.g. RHEL 7, and the user may inadvertently use an internal
> > function without knowing it.

The function is marked as internal.
If the user misses this info and test only with compilers not supporting
the attribute, that's no luck.
What would be the consequence? Having a risk for future compatibility?
It looks to be an acceptable risk.
The other consequence it that we won't have reports for this rare
incompatibility.

> > David, anything else to add here?
> 
> Nop, fair summary.

My preference is for #1:
	pro: No compilation will be impacted in the field
	con: DPDK developers may miss some cases

Any other opinion?