https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115566

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #8 from Harald van Dijk <harald at gigawatt dot nl> ---
I believe this bug is valid; the change from

> A parenthesized expression is a primary expression. Its type and value are
> identical to those of the unparenthesized expression. It is an lvalue, a
> function designator, or a void expression if the unparenthesized expression
> is, respectively, an lvalue, a function designator, or a void expression.

to the already quoted

> A parenthesized expression is a primary expression. Its type, value, and
> semantics are identical to those of the unparenthesized expression.

only makes sense if the intent was to to also make parenthesized expressions
equivalent to unparenthesized expressions in other ways than those previously
enumerated.

But at any rate, GCC is inconsistent. The exact same argument applies to null
pointer constants. Null pointer constants are defined as

> An integer constant expression with the value 0, or such an expression cast
> to type void *, is called a null pointer constant.

Note that such an expression cast to type void *, and then wrapped in
parentheses, is not explicitly included.

Yet GCC accepts

  #define NULL ((void*)0)
  int main(void) {
    void(*fp)(void) = NULL;
  }

when the same overly pedantic reading should result in "ISO C forbids
initialization between function pointer and 'void *'" here.

Either parenthesized expressions are just generally equivalent to
non-parenthesized expressions, and both the OP's code and this program are
valid, or parenthesized expressions are only like the non-parenthesized
expressions in the specifically enumerated ways, in which case both the OP's
code and this program violate a constraint and require a diagnostic. You can
choose which of those interpretations you prefer, but they both indicate a bug
in GCC.

Reply via email to