On Fri, Sep 29, 2023 at 12:26 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 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.
So back to the original topic, I get that static_assert is ok for this patch. -- David Marchand
