Am Dienstag, dem 21.01.2025 um 18:40 +0000 schrieb Joseph Myers:
> 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. 

One could allow only a very restricted subset of expressions similar to
how  .len = x  in initializers could also seen as a restricted subset of
the general expression syntax.

Allowing arbitrary expressions also raises other questions, e.g. what to
do about side effects, so my recommendation would be to only allow 
a restricted subset anyway.


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

Coudn't you use the rule that .len refers to the closest enclosing structure
even without __self__ ?  This would then also disambiguate between designators
and other uses.

Martin

> 

Reply via email to