03/10/2022 18:39, Chautru, Nicolas:
> Hi Thomas,
>
> I will update all your comments below today, thanks.
Please do a self review of other patches (I reviewed only this one),
I suspect there are a lot of other details to improve in other places.
> The one where we need your confirmation is specifically this comment from
> your, I believe we discussed but good to make sure we are all aligned:
Yes let's be clear.
> > But the big question is why do we need this "MAX" value?
> > The guideline is to avoid using such MAX value for long term compatibility.
>
> This is not a _MAX enum but a _SIZE_MAX for array related to that enum. Note
> that the actual max value of the enum exists but is used a private macro.
> The distinction is that the application cannot make any assumptions on what
> is the maximum enum value (ie. we don't want enum with MAX value, that is not
> future proof has captured in doc).
> But the application can make some assumption on the sizing of array based on
> such an enum. The difference being the padding which allows for the enum
> growth without breaking ABI or application.
> The previous name was _PADDED_MAX to make it clear this not a max enum but a
> padded value. Then more recenrtly the consensus in the community was to
> change this to _SIZE_MAX to be arguably more explicit this is to be used for
> array size. The comments I believe also make it clear this is not a MAX enum.
>
> Does that make sense and do you agree this is best consensus so far to move
> forward?
It makes a lot of sense to me because this is what I proposed 2 or 3 years ago
to the techboard when we approached different general solutions.
But it has been said that it is not ideal for 2 reasons I think:
- there is a compatibility breakage when we reach the maximum
- there is no assumption on how the padding is filled
That's why the preferred way should be to avoid having any maximum value.
For instance, array allocation and iteration could be done in the API.
Anyway I'm fine with your solution for now.
