lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180315125030.GA4727@krava>
Date:   Thu, 15 Mar 2018 13:50:30 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...hat.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Wang Nan <wangnan0@...wei.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: New -Werror=restrict error with incremental gcc

On Wed, Mar 14, 2018 at 02:19:41PM -0700, Laura Abbott wrote:
> Hi,
> 
> Fedora picked up a new gcc (8.0.1-0.18.fc29) and it seems to have introduced a new error:
> 
>   gcc -Wp,-MD,/home/labbott/linux/tools/objtool/.str_error_r.o.d -Wp,-MT,/home/labbott/linux/tools/objtool/str_error_r.o -Wall -Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wno-switch-default -Wno-switch-enum -Wno-packed -fomit-frame-pointer -O2 -g -I/home/labbott/linux/tools/include -I/home/labbott/linux/tools/arch/x86/include/uapi -I/home/labbott/linux/tools/objtool/arch/x86/include -I/home/labbott/linux/tools/lib -D"BUILD_STR(s)=#s" -c -o /home/labbott/linux/tools/objtool/str_error_r.o ../lib/str_error_r.c
> ../lib/str_error_r.c: In function ‘str_error_r’:
> ../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
>    snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, buf, buflen, err);
>    ^~
> 
> This looks like gcc is now warning about the aliasing from printing out buf
> while printing to the buffer. I can work around this pretty easily but I
> know people have strong opinions about gcc warnings. Any thoughts?

I did not get above warning.. objtool compiled for me properly

but we have some issues with perf there, I have to use
following to get it compile, plus attached patch

  make EXTRA_CFLAGS="-Wno-format-truncation -Wno-cast-function-type"

the format-truncation are mostly fine, because we use the
buffer len to be safe and the worst things that will happen
is that we won't open the file, because the path is too long

the cast-function-type seems like a problem, I've bunch
of following errors:

	 /root/linux/tools/perf/util/python.c:830:15: warning: cast between incompatible function types from ‘PyObject * (*)(struct pyrf_evsel *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct pyrf_evsel *, struct _object *, struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Wcast-function-type]
	   .ml_meth  = (PyCFunction)pyrf_evsel__open,
		       ^
	/root/linux/tools/perf/util/python.c:1052:15: warning: cast between incompatible function types from ‘PyObject * (*)(struct pyrf_evlist *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct pyrf_evlist *, struct _object *, struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Wcast-function-type]
	   .ml_meth  = (PyCFunction)pyrf_evlist__mmap,
		       ^
	/root/linux/tools/perf/util/python.c:1058:15: warning: cast between incompatible function types from ‘PyObject * (*)(struct pyrf_evlist *, PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct pyrf_evlist *, struct _object *, struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Wcast-function-type]
	   .ml_meth  = (PyCFunction)pyrf_evlist__open,

we might want to look at it.. there were some python related
changes recently, like v3 support.. Arnaldo?

thanks,
jirka


---
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index cce926aeb0c0..48696fd80ad1 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2721,7 +2721,7 @@ static int check_ev_match(char *dir_name, char *scriptname,
 	int match, len;
 	FILE *fp;
 
-	sprintf(filename, "%s/bin/%s-record", dir_name, scriptname);
+	scnprintf(filename, MAXPATHLEN, "%s/bin/%s-record", dir_name, scriptname);
 
 	fp = fopen(filename, "r");
 	if (!fp)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ