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).
> > > >
> > >
> >
>
