Hi, Joseph, Thanks a lot for your comments.
I do have some questions below since I am not very sure how to come up with good testing cases for these cases. > On Nov 10, 2025, at 14:47, Joseph Myers <[email protected]> wrote: > > On Fri, 7 Nov 2025, Qing Zhao wrote: > >> + gcc_assert (TYPE_NAME (outmost_struct_type) != NULL); > >> + /* If the type of the containing structure is an anonymous struct/union, >> + get the first outer named structure/union type. */ >> + while (TYPE_NAME (type) == NULL_TREE) > > I'm not sure that TYPE_NAME being NULL_TREE is always the right check. > You can have a struct or union with no tag that is its own top-level type, > not an example of the anonymous structs and unions feature; that only > applies when the *field* with the struct or union type has no name (in > addition to the struct or union itself having no name - and some > extensions allow a named struct or union to be used with an unnamed field > as well) - and when the field is declared directly with a structure or > union specifier (not typedef or typeof for such - again, some extensions > allow that). > > So, for example, > > struct { int a; char b[] __attribute__ ((counted_by (a))); } *x; For such case, usually how to initialize the above x? Since the anonymous structure has a FAM field, usually we need to use malloc to initialize it, is this correct? Or is there other way to initialize such variable? If we have to use malloc to initialize, how to do it? (There is no structure name, how can we get the size of the structure?) one way to do it is to manually calculate the size of the anonymous structure with use malloc to initialize. > > is a legitimate use of an unnamed structure type, where the counted_by > checks should take place at the level of that type rather than expecting > it to appear in a larger type. Similarly, if you name the field using a > type without a tag, > > struct s { struct { int a; char b[] __attribute__ ((counted_by (a))); } x; }; Again, for this case, how to initialize a variable with “stuct s”? > > then again, the checks should take place in the context of the inner, > unnamed structure type. It's only when the *field* is unnamed that the > members of the unnamed struct or union are considered members of the > containing struct or union and so should all be considered together for > counted_by purposes. > > This means the patch should include testcases (both valid, and invalid > ones being diagnosed) with unnamed structure or union types used in > contexts that *don't* insert their members into the namespace of some > outer structure or union, and verify that the compiler behaves as expected > on such cases (and I suspect the code based on TYPE_NAME will need > changing to make it behave correctly). Does the above two cases you listed cover all such cases? Thanks a lot for your help. Qing > > -- > Joseph S. Myers > [email protected] >
