Hi Joseph,

On Tue, Oct 14, 2025 at 03:49:58PM +0000, Joseph Myers wrote:
> On Tue, 14 Oct 2025, Alejandro Colomar wrote:
> 
> > +/* Parse a _Maxof or _Minof expression.  */
> > +
> > +static struct c_expr
> > +c_parser_maxof_or_minof_expression (c_parser *parser, enum rid rid)
> > +{
> > +  const char *op_name = (rid == RID_MAXOF) ? "_Maxof" : "_Minof";
> > +  struct c_expr expr;
> > +  struct c_expr result;
> > +  location_t expr_loc;
> > +  gcc_assert (c_parser_next_token_is_keyword (parser, rid));
> > +
> > +  location_t start;
> > +  location_t finish = UNKNOWN_LOCATION;
> > +
> > +  start = c_parser_peek_token (parser)->location;
> > +
> > +  pedwarn_c23 (start, OPT_Wpedantic,
> > +          "ISO C does not support %qs before C2Y", op_name);
> 
> If you're proposing something as an extension, it would be pedwarn, not 
> pedwarn_c23; pedwarn_c23 is only relevant if actually accepted into C2Y.

This initial draft, I wrote it as if it were going to be the standard
feature.  If you agree to merge it as an extension, I'll hapily edit the
pedantic diagnostics accordingly.

> > +  c_inhibit_evaluation_warnings++;
> > +  if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
> > +      && c_token_starts_compound_literal (c_parser_peek_2nd_token 
> > (parser)))
> > +    {
> > +      /* Either operator ( type-name ) or operator unary-expression
> > +    starting with a compound literal.  */
> 
> All this logic is massively overcomplicated for something that only 
> accepts a type name and not an expression at all.  Don't copy irrelevant 
> logic from other syntax constructs that's not needed here.  Just parse a 
> type name in parentheses (and thus you don't need to handle storage class 
> specifiers that might appear for a compound literal either, for example).  

I'll have a look at simplifying it.  I tried, but I don't know the code
enough to know how to simplify some things.  But I can try harder.  :)

> (And if the feature did end up supporting expressions as well,

I've been thinking about it, and I don't think we want to handle
expressions, for several reasons:

-  None of my code needs it.  All uses I have of the macro in my code,
   I call it with a type name.

-  It avoids confusion with MAX() and MIN().  Especially, since

        _Maxof(1, 2)

   would be syntactically correct, using a comma operator.

> then 
> refactoring things so that the logic for "unary expression or 
> parenthesized type name" doesn't need replicating for all of 
> sizeof/countof, alignof (as an extension) and maxof/minof would be a good 
> idea, though maybe complicated by the various evaluation and error 
> handling logic.)

I'll have a look at a later refactor.  However, I don't feel qualified
for that yet.  :-)


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

Attachment: signature.asc
Description: PGP signature

Reply via email to