linux-kernel - Re: [PATCH] tools: Fix str_error

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]

Date:   Mon, 19 Mar 2018 16:44:56 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] tools: Fix str_error_r() Werror=restrict build

On (03/19/18 08:18), Jiri Olsa wrote:
> On Mon, Mar 19, 2018 at 02:55:04PM +0900, Sergey Senozhatsky wrote:
> > Commit c8b5f2c96d1bf6c ("tools: Introduce str_error_r()") added
> > an str_error_r() wrapper which makes gcc8 unhappy due to
> > restrict-qualified parameter aliasing violation:
> > 
> > ../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);
> >    ^~~~~~~~
> > cc1: all warnings being treated as errors
> > 
> > Workaround that aliasing error by creating an additional stack
> > variable which holds the buf pointer value we passed to strerror_r().
> > 
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
> 
> Josh posted another way to fix it:
> https://marc.info/?l=linux-kernel&m=152116992412107&w=2

Oh, thanks for the pointers.

> your patch keeps the same output, I dont mind either way ;-)

Thanks. No strong opinion, either way is OK :) Can't tell for sure if
snprintf(... "%p", buf) is significantly better than snprintf(... "[buf]"),
but Arnaldo wanted to have the first version.

	-ss