> On Oct 21, 2024, at 17:29, Martin Uecker <uec...@tugraz.at> wrote:
>
> Am Montag, dem 21.10.2024 um 21:09 +0000 schrieb Joseph Myers:
>> On Sat, 19 Oct 2024, Martin Uecker wrote:
>>
>>> Hi Quin and Joseph,
>>>
>>> I saw that there is now new code in tu_tagged_types_compatible
>>> which makes structure type incompatible depending on whether
>>> there is ac counted_by attribute. Is this what we want? I think a
>>> warning might make more sense as this types are fundamentally
>>> still compatible.
>>
>> If the types were compatible you'd need a composite type. If the
>> composite type has the flexible array counted by both the integer elements
>> named with counted_by attributes (one in one of the types and one in the
>> other), that really doesn't make sense to me.
>
> I doesn't really make sense when they are inconsistent.
> Still, we could just warn and pick one of the attributes
> when forming the composite type.
If both are defined locally, such inconsistencies should be very easily fixed
in the source code level.
And I think that such inconsistencies should be fixed in the source code.
Therefore, reporting error
makes more sense to me.
>
> But I was thinking about the case where you have a type with
> a counted_by attribute and one without. Using them together
> seems useful, e.g. to add a counted_by in your local version
> of a type which needs to be compatible to some API.
For API compatibility purpose, yes, I agree here.
A stupid question here: if one is defined locally, the other one is NOT defined
locally, can such inconsistency be caught by the same compilation (is this the
LTO compilation?)
Suppose we can catch such inconsistency in the same compilation, which version
we should keep? I guess that we should keep the version without the counted_by
attribute?
thanks.
Qing
>
> Martin
