On Thu, Jan 28, 2021 at 6:36 PM Bruce Richardson <bruce.richard...@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. > > 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. > > David, anything else to add here? Nop, fair summary. -- David Marchand
