On Tue, Jan 21, 2025 at 10:40 AM Joseph Myers <josmy...@redhat.com> wrote:
> On Tue, 21 Jan 2025, Qing Zhao wrote:
> > So, even after we introduce the designator syntax for counted_by attribute,
> > arbitrary expressions as:
> >
> > counted_by (.len1 + const)
> > counted_by (.len1 + .len2)
> >
> > Still cannot be supported?
>
> Indeed. Attempting to use ".len1" inside something that looks like an
> expression is fundamentally ambiguous, as I've noted in previous
> discussions of such syntax. Consider
>
> counted_by ((struct s) { .len1 = x }.len1)
>
> where you now have an ambiguity of whether ".len1 = x" is a designated
> initializer for the compound literal of type struct s, or an assignment to
> ".len1" within the structure referred to in counted_by.
>
> > If not, how should we support simple expressions for counted_by attribute?
>
> First, I should point out that the proposed standard feature in this area
> (which received along-the-lines support at the WG14 meeting in Strasbourg
> last year, though with a very large number of issues with the proposed
> wording that would need to be resolved for any such feature to go in, and
> without support for another paper needed for the feature to be useful) was
> intentionally limited; it didn't try for general expressions, just for
> .IDENTIFIER, where IDENTIFIER named a *const-qualified* structure member
> (that thus had to be set when the structure was initialized and not
> modified thereafter, so avoiding various of the complications we have with
> counted_by of defining exactly when the value applies in relation to
> accesses to different structure members).
>
Do you have a URL to the proposal?
> But if you want a less-limited feature that allows for expressions, you
> need some syntax for referring to a structure member that's not ambiguous.
> For example, some new notation such as __self__.len1 to refer to a member
> of the closest enclosing structure definition when in counted_by (while
> being invalid except in counted_by inside a structure definition).
> (That's just one example of how you might define syntax that avoids
> ambiguity.)
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
