| Message ID | 4F8CAE5B.40708@oracle.com |
|---|---|
| State | New |
| Headers | show |
I have various thoughts:
It's odd that we still treat 'return' as starting a function body long
after we removed that extension.
Maybe we shouldn't look for a function body if we already have an
initializer and aren't dealing with a function declarator.
I guess we should set initializer_token_start for {} initializers as well.
But your patch is certainly the smallest change, and OK.
Jason
On 04/17/2012 03:55 PM, Jason Merrill wrote: > I have various thoughts: > > It's odd that we still treat 'return' as starting a function body long > after we removed that extension. > > Maybe we shouldn't look for a function body if we already have an > initializer and aren't dealing with a function declarator. > > I guess we should set initializer_token_start for {} initializers as > well. > > But your patch is certainly the smallest change, and OK. Thanks. Thus let's say I apply the very safe patchlet to mainline and branch and then, when time allows, I'll try and see if I clean up a bit mainline in this area. Thanks, Paolo.
Index: testsuite/g++.dg/parse/crash59.C =================================================================== --- testsuite/g++.dg/parse/crash59.C (revision 0) +++ testsuite/g++.dg/parse/crash59.C (revision 0) @@ -0,0 +1,3 @@ +// PR c++/53003 + +struct A{ void a{} return b // { dg-error "function definition|expected" } Index: cp/parser.c =================================================================== --- cp/parser.c (revision 186509) +++ cp/parser.c (working copy) @@ -19109,7 +19109,7 @@ cp_parser_member_declaration (cp_parser* parser) possible that this fact is an oversight in the standard, since a pure function may be defined outside of the class-specifier. */ - if (initializer) + if (initializer && initializer_token_start) error_at (initializer_token_start->location, "pure-specifier on function-definition"); decl = cp_parser_save_member_function_body (parser,
Hi, I had a look to this Segmentation fault in cp_parser_member_declaration and what happens is that initializer_token_start is still null (as initialized) when we get to: if (initializer) error_at (initializer_token_start->location, "pure-specifier on function-definition"); the trivial check avoids the Seg fault (and would be safe, for 4.7 too) but I'm not sure if we want to bail out a bit earlier. Tested x86_64-linux. Thanks, Paolo. //////////////////////// /cp 2012-04-16 Paolo Carlini <paolo.carlini@oracle.com> PR c++/53003 * parser.c (cp_parser_member_declaration): Check that initializer_token_start is non null before dereferencing it. /testsuite 2012-04-16 Paolo Carlini <paolo.carlini@oracle.com> PR c++/53003 * g++.dg/parse/crash59.C: New.