> On Jun 11, 2025, at 09:36, Qing Zhao <qing.z...@oracle.com> wrote:
>
>
>
>> On Jun 10, 2025, at 17:01, Joseph Myers <josmy...@redhat.com> wrote:
>>
>> On Tue, 13 May 2025, Qing Zhao wrote:
>>
>>> + /* This attribute cannot be applied to a pointer type whose pointee type
>>> + is void. */
>>> + else if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE
>>> + && TREE_CODE (TREE_TYPE (TREE_TYPE (decl))) == VOID_TYPE)
>>> + {
>>> + error_at (DECL_SOURCE_LOCATION (decl),
>>> + "%qE attribute is not allowed for a pointer field"
>>> + " with void pointee type", name);
>>> + *no_add_attrs = true;
>>> + }
>>
>> I think it should also be disallowed for a pointer to function, since the
>> number of elements of the array makes no sense in that case. (This will
>> need test and documentation updates as well.)
>
> Yes, that’s right, I will update the patch with this.
>>
>> However, I think it should be allowed for a pointer to non-void incomplete
>> types (incomplete structure or union); in that case, the type would need
>> to be completed in the context where a dereference occurs. Since that's
>> already supported in the code, there should probably be tests added for
>> that case.
>
> Sure, I will check for this and add tests.
When I was adding more testing cases for the pointee type being
structure/union, I have a question for the following case:
struct item5 {
int a;
float b[];
};
struct pointer_array_9 {
...
int count5;
struct item5 *array_5 __attribute__ ((counted_by (count5)));
};
In the above, “struct item5” is a structure type with flexible array member,
whose size is not know during compilation time, as
a result, the size of the whole structure is unknown during compilation time,
shall we reject such cases?
Thanks.
Qing
>
>>
>> I think saying "pointer to void" is better than "pointer field with void
>> pointee type".
>
> Okay, will update.
>
> Thanks a lot.
>
> Qing
>>
>> --
>> Joseph S. Myers
>> josmy...@redhat.com
