"Kinsella, Ray" <m...@ashroe.eu> writes:
> On 22/01/2021 13:09, Dodji Seketeli wrote:
>> Thomas Monjalon <tho...@monjalon.net> writes:
>>
>> [...]
>>
>>>>> Then I've added (quickly) a libabigail exception rule:
>>>>>
>>>>> [suppress_type]
>>>>> name = rte_cryptodev
>>>>> has_data_member_inserted_between = {0, 1023}
>>>>>
>>>>> Now we want to improve this rule to restrict the offsets
>>>>> to the padding at the end of the struct only,
>>>>> so we keep forbidding changes in existing fields,
>>>>> and forbidding additions further the current struct size.
>>>>> Is this new rule good?
>>>>>
>>>>> has_data_member_inserted_between = {offset_after(attached), end}
>>>>
>>>>
>>>> Yes, this rule should do what you think it says.
>>>>
>>>>> Do you confirm that the keyword "end" means the old reference size?
>>>>
>>>> Yes I do.
>>>>
>>>>
>>>>> What else do we need to check for adding a new field in a padding?
>>>>
>>>> Actually, that rule will work independantly of it there is enough
>>>> padding or not. It'll shut down the change report, even if the added
>>>> data exceeds the padding.
>>>
>>> I don't understand why.
>>> If "end" means the old reference size, then addition after the old size
>>> should be reported, isn't it?
>>
>> Yes, you are right.
>>
>> What I meant is that even if (in an hypothetical case, not yours) the
>> padding was so "small" that it wasn't going up to the 'end' of the
>> struct, that rule would have still shut down the change report.
>
> Understood - you are talking about padding between members.
Exactly.
Cheers,
--
Dodji
