> >>> 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-gmuthukri...@marvell.com/ This was merged yesterday.
