Patchwork [C++] PR 53003

login
register
mail settings
Submitter Paolo Carlini
Date April 16, 2012, 11:42 p.m.
Message ID <4F8CAE5B.40708@oracle.com>
Download mbox | patch
Permalink /patch/153013/
State New
Headers show

Comments

Paolo Carlini - April 16, 2012, 11:42 p.m.
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.
Jason Merrill - April 17, 2012, 1:55 p.m.
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
Paolo Carlini - April 17, 2012, 3:37 p.m.
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.

Patch

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,