> On Oct 25, 2024, at 08:13, Martin Uecker <uec...@tugraz.at> wrote:
>
>>> 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.
>
> I am not entirely sure what you mean by this.
>
> These are two different types in different scopes, so they
> are allowed to be different.
Okay, so the two types, aaa_t and the “struct foo” inside the function “foo”,
are two different types.
And this is legal.
>
> But _Generic then tests whether they are compatible and
> takes the attribute into account for GCC.
Then, these two types are not compatible due to the attribute, is this correct?
> But for
> earlier GCC or other compilers that do not support the
> attribute the result would be different.
For a compiler that does not support the “counted_by” attribute, if the
compiler reports error for the unsupported attribute, then the user needs to
modify the source code to eliminate the unsupported attribute, then the problem
should be resolved by the user?
If the compiler just ignores the unsupported attribute, then these two types
will be treated compatible types by the compiler. Will doing this cause any
issue? Since the “counted-by” attribute is not supported by the compiler and is
ignored by the compiler, these two types should be compatible from my
understanding, do I miss anything obvious here?
Qing
>
> So maybe instead of changing the return value of comptypes,
> we simply set different_types_p (which would prevent
> redeclaration in the same scope) and also set another flag
> similar to enum_and_int_p (e.g. inconsistent_counted_by_p)
> and emit an error in the callers at some appropriate places.
>
>>>
>>> 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.
>
> Yeah, but here we will miss many other inconsistencies too...
>
>>
>>>
>>>> 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
>>
>
>
> Martin
>
>> .
>>
>> Thanks.
>> Qing
>>>
>>>
>>> Martin
>>
>>
>
> --
> Univ.-Prof. Dr. rer. nat. Martin Uecker
> Graz University of Technology
> Institute of Biomedical Imaging
