> On Oct 22, 2024, at 15:16, Martin Uecker <uec...@tugraz.at> wrote:
>
>>>>
>>>
>>> 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.
>
> I agree, and error makes sense. What worries me a little bit
> is tying this to a semantic change in type compatibility.
>
> typedef struct foo { int n; int m;
> [[gnu::counted_by(n)]] char buf[]; } aaa_t;
>
> void foo()
> {
> struct foo { int n; int m;
> [[gnu::counted_by(m)]] char buf[]; } *b;
>
> ... = _Generic(b, aaa_t*: 1, default: 0);
> }
>
> would go into the default branch for compilers supporting
> the attribute but go into the first branch for others. Also
> it affects ailasing rules.
So, they are in separate compilations? Then the compiler is not able to catch
such
inconsistency during compilation time.
>
> But maybe this is not a problem.
This does look like an issue to me…
Not sure how to resolve such issue at this moment.
Or, only when the “counted_by” information is included into the TYPE, such
issue can be resolved?
>
>>>
>>> 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?)
>
> If there is separate compilation this is not catched. LTO
> has a much coarser notion of types and would not notice
> either (I believe).
Okay. Then such inconsistency will not be caught during compilation time.
>
>> 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?
>>
> I would keep the one with the attribute, because this is the
> one which has more information.
Make sense to me.
Thanks.
Qing
>
>
> Martin
