> On Nov 13, 2025, at 14:17, Martin Uecker <[email protected]> wrote:
>
> Am Donnerstag, dem 13.11.2025 um 15:44 +0000 schrieb Qing Zhao:
>>
>>> On Nov 13, 2025, at 01:32, Martin Uecker <[email protected]> wrote:
>>>
>>> Am Mittwoch, dem 12.11.2025 um 22:07 +0000 schrieb Joseph Myers:
>>>> On Wed, 12 Nov 2025, Qing Zhao wrote:
>>>>
>>>>>> There are the various extensions (-fms-extensions / -fplan9-extensions)
>>>>>> to
>>>>>> consider as well, but it might be reasonable to say that only genuinely
>>>>>> anonymous struct / union members get the special counted_by handling,
>>>>>
>>>>> So, in C FE, what’s the best way to determine whether the anonymous
>>>>> struct/union is
>>>>> genuine or not? (The DECL_CONTEXT of this anonymous structure/union is
>>>>> NULL_TREE?)
>>>>
>>>> You can't tell until some time after the definition is complete, because
>>>> you need to see whether the type is used as the type of an unnamed field
>>>> (possibly with qualifiers).
>>>>
>>>> Maybe this suggests that, as in other cases, an anonymous structure or
>>>> union involving counted_by should actually be required to be valid without
>>>> reference to the containing struct or union after all - that's how things
>>>> generally work with anonymous structs and unions. That is, it would be OK
>>>> for an outer struct or union to have counted_by pointing to a count in an
>>>> inner anonymous struct or union, but not vice versa.
>>>
>>> Without -fms-extensions, anonymous structs are supported only
>>> if they are defined inline. The following is rejected with
>>> --pedantic-errors but even without it an access to .buf would
>>> be rejected.
>>>
>>> typedef struct { char *buf; } x_t;
>>>
>>> struct foo {
>>> int n;
>>> x_t;
>>> };
>>>
>>>
>>> But if they are declined inline
>>>
>>> struct foo {
>>> int n;
>>> struct { char *buf; };
>>> };
>>>
>>
>> You mean the following case:
>>
>> struct foo {
>> Int n;
>> struct {
>> char *buf __counted_by (n);
>> }
>> }
>
> Yes, I think this could be supported.
This is the request from PR122495/PR122496. And my current patch was able to
support it.
>>
>>
>>> In this, counted_by could be supported and you would need to check
>>> for the field name to NULL_TREE, i.e. DECL_NAME (...) == NULL_TREE and
>>> also c_type_tag (...) == NULL_TREE.
>>
>> i.e, both the name of the field type and the name of the field are NULL_TREE?
>
> TYPE_NAME may also hold a typedef name. This may or may not be
> what you want. If you want to resolved typedef names and get the tag,
> you need to use c_type_tag.
Okay, I see.
>
>>
>>>
>>> You would then check correctness of the attribute only when the parent
>>> type is complete.
>>
>> Okay.
>>>
>>> If we want to support counted_by in even more generic cases,
>>
>> What kind of more generic cases? Any example?
>
> I was thinking about
>
> struct bar {
> char *buf __counted_by(n);
> };
>
> struct foo {
> int n;
> struct bar;
> };
>
> which is allowed with -fms-extensions.
>
> I don't think we should support this.
Don’t support this even when -fms-extensions is enabled?
>
>>
>> How about the following? Shall we support it?
>>
>> struct nested_mixed {
>> struct {
>> union {
>> int b;
>> float f;
>> };
>> int n;
>> };
>> struct {
>> int *pointer __counted_by(n);
>> char c[] __counted_by(b);
>> };
>> };
>
> I think this could be allowed because everythig is inline.
Yeah, my current patch support this too.
Qing
>
> Martin
>
>>
>>
>> Thanks a lot.
>>
>> Qing
>>> I think
>>> checking would need to deferred to declaration of variables, but
>>> I am not sure this is a good idea.
>>>
>>> Martin
