[C++ Patch] PR 53003

[C++ Patch] PR 53003

[Paolo Carlini]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

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.

////////////////////////

[-- Attachment #2: CL_53003 --]
[-- Type: text/plain, Size: 303 bytes --]

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

[-- Attachment #3: patch_53003 --]
[-- Type: text/plain, Size: 931 bytes --]

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,

Re: [C++ Patch] PR 53003

[Jason Merrill]

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

Re: [C++ Patch] PR 53003

[Paolo Carlini]

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.