On 1/30/2020 3:59 PM, Thomas Monjalon wrote: > 30/01/2020 14:06, Trahe, Fiona: >> We were unaware the LIST_END change could constitute an ABI breakage, but >> can see how it affects the array size when picked up. >> We're exploring options. >> >> I agree with Anoob's point that if we don't allow the LIST_END to be >> modified, then it means no feature can be implemented without ABI breakage. >> Anyone object to removing those LIST_END elements - or have a better >> suggestion? Would have to be in 20.11 I suppose. > > Yes, having max value right after the last value is ridiculous, > it prevents adding any value. > In 20.11, we should remove all these *_END and *_MAX from API enums > and replace them with a separate #define with reasonnable maximums. > >
I disagree, that kind of usage is common and lets loops iterate on the valid elements, and it is not a source of ABI break on its own. Indeed other way around, not having MAX, is problematic, if we don't have the MAX value to compare and decide if a provided value is valid or not, and when new version of the library introduces the new values, how old application can detect unsupported new values? As far as I can see the problem occurs when that *_END and *_MAX used to define the size of array in the public struct. This usage prevents adding new values and I already send a deprecation notice for it: https://patches.dpdk.org/patch/65359/
