Hi, Bill,
Sorry for the late reply (just be back from a short vacation).
> On Jan 23, 2025, at 17:44, Bill Wendling <isanb...@gmail.com> wrote:
>
> On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao <qing.z...@oracle.com> wrote:
>>
>> Hi, Bill,
>>
>> Thanks a lot for your testing case.
>>
>> I studied this testing case and realized that we need to decide
>> what’s the expected behavior for the following situation:
>>
>> struct bar;
>>
>> struct a {
>> int dummy;
>> struct bar *array __attribute__((counted_by(count)));
>> char count;
>> };
>>
>> when the size information of the element of the pointer array is not
>> available
>> in the current compilation, i.e., there is no definition of the structure
>> “bar” in the
>> current file, the size of “structure bar” is not known, as a result,
>> compilation is not
>> able to compute the object size of the pointer array “array” even though the
>> length
>> of the array is known.
>>
>> So, my question is:
>>
>> 1. When should the compiler issue warning for such situation?
>> A. During C frontend when checking the counted_by attributes.
>> B. During middle-end when __builtin_dynamic_object_size is computing the
>> object size.
>>
>> I prefer B. The reason is: even though the counted_by attribute under such
>> situation is not enough for object_size,
>> It should be enough for the bound sanitizer?
>>
> My feelings on this is that we should allow this in the struct
> declaration, because when the user goes to allocate the objects for
> 'array', struct bar will be defined. So there shouldn't be an issue.
> There are two possible uses (maybe more) that I can think of:
>
> ptr->array = malloc (sizeof (struct bar));
> ptr->count = 1;
>
> or
>
> ptr->array = malloc (sizeof (struct bar) * count);
> ptr->count = count;
>
> And then you can access the 5th element like this:
>
> (((char *) ptr->array) + sizeof (struct bar) * 5).some_element;
A CLANG patch that is currently under review is trying to resolve this similar
issue:
https://github.com/llvm/llvm-project/pull/106321
This patch proposed the following rule to handle such situation:
" • For incomplete pointee types that can never be completed (e.g. void) these
are treated as error where the attribute is written (just like before this
patch).
• For incomplete pointee types that might be completable later on (struct,
union, and enum forward declarations) in the translation unit, writing the
attribute on the incomplete pointee type is allowed on the FieldDecl
declaration but "uses" of the declared pointer are forbidden if at the point of
"use" the pointee type is still incomplete.
For this patch a "use" of a FieldDecl covers:
• Explicit and Implicit initialization (note see Tentative Definition
Initialization for an exception to this)
• Assignment
• Conversion to an lvalue (e.g. for use in an expression)
“
I think that the above rule is reasonable to handle such situation.
Let me know if you have any comment or suggestion on this.
Qing
>
> (Gotta love C.)
>
> -bw
