> On Jun 7, 2023, at 6:05 PM, Joseph Myers <jos...@codesourcery.com> 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 not identify that this identifier is a field identifier inside >> the same structure. >> >> For example: >> >> int count; >> struct trailing_array_7 { >> Int count; >> int array_7[] __attribute ((element_count (count))); >> }; >> >> The identifier “count” inside the attribute will refer to the variable >> “int count” outside of the structure. > > c_parser_attribute_arguments is supposed to allow an identifier as an > attribute argument - and not look it up (the user of the attribute would > later need to look it up in the context of the containing structure). > Callers use attribute_takes_identifier_p to determine which attributes > take identifiers (versus expressions) as arguments, which would need > updating to cover the new attribute. > > There is a ??? comment about the case where the identifier is declared as > a type name. That would simply be one of the cases carried over from the > old Bison parser, and it would seem reasonable to remove that > special-casing so that the attribute works even when the identifier is > declared as a typedef name as an ordinary identifier, since it's fine for > structure members to have the same name as a typedef name. > > Certainly taking an identifier directly seems like cleaner syntax than > taking a string that then needs reinterpreting as an identifier.
Thanks a lot for the helpful info. I will study a little bit here to see how to do this. Qing > > -- > Joseph S. Myers > jos...@codesourcery.com