RE: [EXTERNAL] Re: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs

[Akhil Goyal <gakhil@marvell.com>]

> >>> Now added inline APIs for getting the list end which need to be updated
> >>> for each new entry to the enum. This shall help in avoiding ABI break
> >>> for adding new algo.
> >>>
> >>
> >> Hi Akhil,
> >>
> >> *I think* this hides the problem instead of fixing it, and this may be
> >> partially because of the tooling (libabigail) limitation.
> >>
> >> This patch prevents the libabigail warning, true, but it doesn't improve
> >> anything from the application's perspective.
> >> Before or after this patch, application knows a fixed value as END value.
> >>
> >> Not all changes in the END (MAX) enum values cause ABI break, but tool
> >> warns on all, that is why I think this may be tooling limitation [1].
> >> (Just to stress, I am NOT talking about regular enum values change, I am
> >> talking about only END (MAX) value changes caused by appending new enum
> >> items.)
> >>
> >> As far as I can see (please Dodji, David correct me if I am wrong) ABI
> >> break only happens if application and library exchange enum values in
> >> the API (directly or within a struct).
> >
> > - There is also the following issue:
> > A library publicly exports an array sized against a END (MAX) enum in the API.
> > https://developers.redhat.com/blog/2019/05/06/how-c-array-sizes-become-part-of-the-binary-interface-of-a-library
> >
> 
> I see. And Dodji explained this requires source code to detect.
> 
> I don't remember seeing a public array whose size is defined by an enum,
> are you aware of any instance of this usage?

https://patches.dpdk.org/project/dpdk/patch/20241009071151.1106-1-gmuthukrishn@marvell.com/
This was merged yesterday.