29/09/2023 11:34, David Marchand: > On Fri, Sep 29, 2023 at 11:26 AM Bruce Richardson > <bruce.richard...@intel.com> wrote: > > > > On Fri, Sep 29, 2023 at 11:02:38AM +0200, David Marchand wrote: > > > On Fri, Sep 29, 2023 at 10:54 AM Morten Brørup > > > <m...@smartsharesystems.com> wrote: > > > > In my opinion, our move to C11 thus makes RTE_BUILD_BUG_ON obsolete. > > > > > > That's my thought too. > > > > > > > > > > > We should mark RTE_BUILD_BUG_ON as deprecated, and disallow > > > > RTE_BUILD_BUG_ON in new code. Perhaps checkpatches could catch this? > > > > > > For a clear deprecation of a part of DPDK API, I don't see a need to > > > add something in checkpatch. > > > Putting a RTE_DEPRECATED in RTE_BUILD_BUG_ON directly triggers a build > > > warning (caught by CI since we run with Werror). > > > > > > > Would it not be sufficient to just make it an alias for the C11 static > > assertions? It's not like its a lot of code to maintain, and if app users > > have it in their code I'm not sure we get massive benefit from forcing them > > to edit their code. I'd rather see it kept as a one-line macro purely from > > a backward compatibility viewpoint. We can replace internal usages, though > > - which can be checked by checkpatch. > > No, there is no massive benefit, just trying to reduce our ever > growing API surface. > > Note, this macro should have been kept internal but it was introduced > at a time such matter was not considered...
I agree with all. Now taking techboard hat, we agreed to avoid breaking API if possible. So we should keep RTE_BUILD_BUG_ON forever even if not used. Internally we can replace its usages.
