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

29/01/2021 09:35, David Marchand:

On Thu, Jan 28, 2021 at 6:36 PM Bruce Richardson
[off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

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*

quoted

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.

quoted

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.

quoted

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?