[PATCH] perf, ui: Eliminate stack-smashing protection compiler complain

[PATCH] perf, ui: Eliminate stack-smashing protection compiler complain

[Cyrill Gorcunov]

 The gcc complains on Yes, No being allocated from stack space. Make
them conts to feel compiler happy.

 |    CC util/ui/util.o
 | cc1: warnings being treated as errors
 | util/ui/util.c: In function ‘ui__dialog_yesno’:
 | util/ui/util.c:108: error: not protecting function: no buffer at least 8 bytes long
 | make: *** [util/ui/util.o] Error 1

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: Frédéric Weisbecker <fweisbec@gmail.com>
CC: Ingo Molnar <mingo@elte.hu>
---

Since it seems only me who has such error I presume ssp-buffer-size=8 set
for mine local version of gcc (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4))

 tools/perf/util/ui/util.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-2.6.git/tools/perf/util/ui/util.c
=====================================================================
--- linux-2.6.git.orig/tools/perf/util/ui/util.c
+++ linux-2.6.git/tools/perf/util/ui/util.c
@@ -104,9 +104,10 @@ out_destroy_form:
 	return rc;
 }
 
+static const char yes[] = "Yes", no[] = "No";
+
 bool ui__dialog_yesno(const char *msg)
 {
 	/* newtWinChoice should really be accepting const char pointers... */
-	char yes[] = "Yes", no[] = "No";
-	return newtWinChoice(NULL, yes, no, (char *)msg) == 1;
+	return newtWinChoice(NULL, (char *)yes, (char *)no, (char *)msg) == 1;
 }

Re: [PATCH] perf, ui: Eliminate stack-smashing protection compiler complain

[Frederic Weisbecker]

On Sat, Nov 06, 2010 at 11:47:24AM +0300, Cyrill Gorcunov wrote:
>  The gcc complains on Yes, No being allocated from stack space. Make
> them conts to feel compiler happy.
> 
>  |    CC util/ui/util.o
>  | cc1: warnings being treated as errors
>  | util/ui/util.c: In function ‘ui__dialog_yesno’:
>  | util/ui/util.c:108: error: not protecting function: no buffer at least 8 bytes long
>  | make: *** [util/ui/util.o] Error 1
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> CC: Arnaldo Carvalho de Melo <acme@redhat.com>
> CC: Frédéric Weisbecker <fweisbec@gmail.com>
> CC: Ingo Molnar <mingo@elte.hu>
> ---



I hope we can finally queue this one fix, the warning is there
for a while now, and this patch looks quite sensible :)



> 
> Since it seems only me who has such error I presume ssp-buffer-size=8 set
> for mine local version of gcc (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4))
> 
>  tools/perf/util/ui/util.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.git/tools/perf/util/ui/util.c
> =====================================================================
> --- linux-2.6.git.orig/tools/perf/util/ui/util.c
> +++ linux-2.6.git/tools/perf/util/ui/util.c
> @@ -104,9 +104,10 @@ out_destroy_form:
>  	return rc;
>  }
>  
> +static const char yes[] = "Yes", no[] = "No";
>  bool ui__dialog_yesno(const char *msg)
>  {
>  	/* newtWinChoice should really be accepting const char pointers... */
> -	char yes[] = "Yes", no[] = "No";
> -	return newtWinChoice(NULL, yes, no, (char *)msg) == 1;
> +	return newtWinChoice(NULL, (char *)yes, (char *)no, (char *)msg) == 1;
>  }

Re: [PATCH] perf, ui: Eliminate stack-smashing protection compiler complain

[Cyrill Gorcunov]

On Sun, Nov 07, 2010 at 10:49:02PM +0100, Frederic Weisbecker wrote:
> On Sat, Nov 06, 2010 at 11:47:24AM +0300, Cyrill Gorcunov wrote:
> >  The gcc complains on Yes, No being allocated from stack space. Make
> > them conts to feel compiler happy.
> > 
> >  |    CC util/ui/util.o
> >  | cc1: warnings being treated as errors
> >  | util/ui/util.c: In function ‘ui__dialog_yesno’:
> >  | util/ui/util.c:108: error: not protecting function: no buffer at least 8 bytes long
> >  | make: *** [util/ui/util.o] Error 1
> > 
> > Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> > CC: Arnaldo Carvalho de Melo <acme@redhat.com>
> > CC: Frédéric Weisbecker <fweisbec@gmail.com>
> > CC: Ingo Molnar <mingo@elte.hu>
> > ---
> 
> I hope we can finally queue this one fix, the warning is there
> for a while now, and this patch looks quite sensible :)
> 

yup, thanks for review ;)