Am Mittwoch, dem 10.04.2024 um 19:35 +0000 schrieb Qing Zhao: > > > On Apr 10, 2024, at 15:05, Martin Uecker <uec...@tugraz.at> wrote: > > > > Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker: > > > Am Mittwoch, dem 10.04.2024 um 17:35 +0000 schrieb Joseph Myers: > > > > On Fri, 29 Mar 2024, Qing Zhao wrote: > > > > > > > > > + /* Issue error when there is a counted_by attribute with a > > > > > different > > > > > + field as the argument for the same flexible array member field. > > > > > */ > > > > > > > > There's another case of this to consider, though I'm not sure where > > > > best > > > > to check for it (Martin might have suggestions) - of course this case > > > > will > > > > need testcases as well. > > > > > > > > Suppose, as allowed in C23, a structure is defined twice in the same > > > > scope, but the two definitions of the structure use inconsistent > > > > counted_by attributes. I'd say that, when the declarations are in the > > > > same scope (thus required to be consistent), it should be an error for > > > > the > > > > two definitions of what is meant to be the same structure to use > > > > incompatible counted_by attributes (even though the member declarations > > > > are otherwise the same). > > > > > > I think the right place could be comp_types_attributes in > > > attributes.cc. It may be sufficient to set the > > > affects_type_identify flag. > > > > > > This should then give a redefinition error as it should do for > > > "packed". > > > > Thinking about this a bit more, this will not work here, because > > the counted_by attribute is not applied to the struct type but > > one of the members. > > > > So probably there should be a check added directly > > to tagged_types_tu_compatible_p > > > There are two cases we will check: > > A. Both definitions are in the same scope; > Then if the 2nd definition has a counted-by attribute different from > the 1st definition, the 2nd definition will be given a redefinition error; > > B. These two definitions are in different scope; > When these two definitions are used in a way need to be compatible, an > incompatible error need to be issued at that > Point; > > > My question is, Will the routine “tagged_types_tu_compatible_p” can handle > both A and B?
Yes, changing this function should address both cases if I am not missing something. Martin > > Thanks. > > Qing > > > > Martin > > > > > > > > > > > > > In C23 structures defined with the same tag in different scopes are > > > > compatible given requirements including compatible types for > > > > corresponding > > > > elements. It would seem most appropriate to me for such structures > > > > with > > > > incompatible counted_by attributes to be considered *not* compatible > > > > types > > > > (but it would be valid to define structures with the same tag, > > > > different > > > > scopes, and elements the same except for counted_by - just not to use > > > > them > > > > in any way requiring them to be compatible). > > > > > > Another option might be to warn about the case when those types > > > are then used together in a way where they are required to > > > be compatible. Then comp_types_attributes would have to return 2. > > > > > > > > > Martin > > > > > > > > > > > > +The @code{counted_by} attribute may be attached to the C99 flexible > > > > > array > > > > > +member of a structure. It indicates that the number of the elements > > > > > of the > > > > > +array is given by the field "@var{count}" in the same structure as > > > > > the > > > > > > > > As noted previously, the "" quotes should be removed there (or replaced > > > > by > > > > ``'' quotes). > > > > > > > > > >