Hi,
Based on the discussion so far and further consideration, the following is my
plan for this new attribute:
1. The syntax of the new attribute will be:
__attribute__((counted_by (count_field_id)));
In the above, count_field_id is the identifier for the field that carries the
number
of el
> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote:
>
> On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>>> So for
>>>
>>> struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; };
>>>
>>> one knows during parsing that the .d is a designator
>>> and that .c is not.
>>
>> There
On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote:
> > So for
> >
> > struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; };
> >
> > one knows during parsing that the .d is a designator
> > and that .c is not.
>
> Therefore, the above should be invalid based on this rule since .c i
> On Jun 16, 2023, at 1:07 PM, Martin Uecker wrote:
>
> Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers:
>> On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
>>
Note that no expressions can start with the '.' token at present. As soon
as you invent a new kin
Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers:
> On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
>
> > > Note that no expressions can start with the '.' token at present. As
> > > soon
> > > as you invent a new kind of expression that can start with that token,
> > >
On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
> > Note that no expressions can start with the '.' token at present. As soon
> > as you invent a new kind of expression that can start with that token, you
> > have syntactic ambiguity.
> >
> > struct s1 { int c; char a[(struct s2 { in
> On Jun 16, 2023, at 3:21 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers:
>> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>>
> ...
>>> 1. Update the routine “c_parser_postfix_expression” (is this the right
>>> place? ) to accept the ne
> On Jun 15, 2023, at 6:48 PM, Joseph Myers wrote:
>
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> B. The argument of the new attribute “counted_by” is an identifier that can
>> be
>> accepted by “c_parser_attribute_arguments”:
>>
>> struct trailing_array_B {
>> Int count;
>>
Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers:
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
...
> > 1. Update the routine “c_parser_postfix_expression” (is this the right
> > place? ) to accept the new designator syntax.
>
> Any design that might work with an exp
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> B. The argument of the new attribute “counted_by” is an identifier that can be
> accepted by “c_parser_attribute_arguments”:
>
> struct trailing_array_B {
> Int count;
> int array_B[] __attribute ((counted_by (count)));
> };
>
>
> From
> On Jun 15, 2023, at 12:55 PM, Joseph Myers wrote:
>
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Comparing B with A, I don’t see too much benefit, either from
>> user-interface point of view, or from implementation point of view.
>>
>> For implementation, both A and B need
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Comparing B with A, I don’t see too much benefit, either from
> user-interface point of view, or from implementation point of view.
>
> For implementation, both A and B need to search the fields of the
> containing structure by the name of
Hi, Joseph,
I studied c_parser_attribute_arguments and related source code,
and also studied PLACEHOLDER_EXPR and related source code.
Right now, I still cannot decide what’s the best user-interface should be for
the
argument of the new attribute “element_count". (Or the new attribute
name “
> On Jun 7, 2023, at 6:05 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Are you suggesting to use identifier directly as the argument of the
>> attribute?
>> I tried this in the beginning, however, the current parser for the attribute
>> argument can n
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Are you suggesting to use identifier directly as the argument of the
> attribute?
> I tried this in the beginning, however, the current parser for the attribute
> argument can not identify that this identifier is a field identifier inside
>
> On Jun 7, 2023, at 4:53 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph,
>>
>> A question here: can an identifier in C be a wide char string?
>
> Identifiers and strings are different kinds of tokens; an identifier can't
> be a string of
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph,
>
> A question here: can an identifier in C be a wide char string?
Identifiers and strings are different kinds of tokens; an identifier can't
be a string of any kind, wide or narrow. It just so happens that the
proposed inte
Hi, Joseph,
A question here: can an identifier in C be a wide char string?
Qing
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of in
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of interface design, or in the present code), but I think that
>>> case should have a
On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
> > What if the string is a wide string? I don't expect that to work (either
> > as a matter of interface design, or in the present code), but I think that
> > case should have a specific check and error.
>
> Dump question: how to check whe
> On May 25, 2023, at 5:02 PM, Joseph Myers wrote:
>
> What happens if the field giving the number of elements is in a contained
> anonymous structure or union?
>
> struct s {
> struct { size_t count; };
> int array[] __attribute__ ((element_count ("count")));
> };
>
> This ought to work -
What happens if the field giving the number of elements is in a contained
anonymous structure or union?
struct s {
struct { size_t count; };
int array[] __attribute__ ((element_count ("count")));
};
This ought to work - a general principle in C is that anonymous structures
and unions are tr
'element_count ("COUNT")'
The 'element_count' attribute may be attached to the flexible array
member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
23 matches
Mail list logo
