Bug 37213 - Declaration/expression ambiguity resolution does not extend beyond initializer
Summary: Declaration/expression ambiguity resolution does not extend beyond initializer
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2008-08-23 20:17 UTC by Argiris Kirtzidis
Modified: 2019-01-10 02:11 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.4.5, 4.5.2, 4.6.0
Last reconfirmed: 2010-12-27 14:36:50


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Argiris Kirtzidis 2008-08-23 20:17:16 UTC
When compiling the following program:


struct S {int z;};
typedef S* (*FuncType)(int,int);
int x,y;
S* a() {
  FuncType(a)(x,y)->z = 0; // treated as declaration
  return 0;
}


This is the result:

t.cpp: In function 'S* a()':
t.cpp:5: error: initializer expression list treated as compound expression
t.cpp:5: error: invalid conversion from 'int' to 'S* (*)(int, int)'
t.cpp:5: error: expected ',' or ';' before '->' token


Shouldn't GCC examine '->' after 'FuncType(a)(x,y)' and conclude that the statement is an expression instead of a declaration ?
Comment 1 Andrew Pinski 2008-08-24 22:28:52 UTC
I think GCC is correct here.
Comment 2 Argiris Kirtzidis 2008-08-24 22:42:37 UTC
I forgot to mention that both MSVC and Comeau compilers interpret

FuncType(a)(x,y)->z = 0;

as expression and compile the test program without errors.
Comment 3 Argiris Kirtzidis 2008-10-08 09:19:00 UTC
And some bit of C++ standard wisdom:
C++ 6.8p1: "To disambiguate, the whole statement might have to be examined to determine if it is an expression-statement or a declaration"

And there's this example given:

T(a)->m = 7; // expression-statement

I think the same applies to the example I gave:

T(a)(x,y)->m = 7; // should be an expression
Comment 4 Johannes Schaub 2010-12-27 11:24:36 UTC
Same problem happens with

int m;
int(m), m++;

I think GCC is wrong rejecting this.
Comment 5 Jonathan Wakely 2010-12-27 14:36:50 UTC
(In reply to comment #0)
> typedef S* (*FuncType)(int,int);
> int x,y;
> S* a() {
>   FuncType(a)(x,y)->z = 0; // treated as declaration

calling 'a' through a function pointer of a different type is undefined behaviour, but fixing that doesn't change the error, which I agree is wrong.