linux-kernel - Re: [PATCH] perf/s390: Compiler error on s390 for bench/numa.c

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: <CAM9d7cjjSk-qyA+ZF2YyrJUeaPN8wi7yDzu+ZRbiM4BhjFvg1A@mail.gmail.com>
Date:   Thu, 19 May 2022 14:45:04 -0700
From:   Namhyung Kim <namhyung@...il.com>
To:     Thomas Richter <tmricht@...ux.ibm.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        linux-perf-users <linux-perf-users@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Sven Schnelle <svens@...ux.ibm.com>, gor@...ux.ibm.com,
        sumanthk@...ux.ibm.com, Heiko Carstens <hca@...ux.ibm.com>
Subject: Re: [PATCH] perf/s390: Compiler error on s390 for bench/numa.c

On Thu, May 19, 2022 at 9:27 AM Thomas Richter <tmricht@...ux.ibm.com> wrote:
>
> The compilation on s390 results in this error:
>
>  # make DEBUG=y bench/numa.o
>  ...
>  bench/numa.c: In function ‘__bench_numa’:
>  bench/numa.c:1749:81: error: ‘%d’ directive output may be truncated
>              writing between 1 and 11 bytes into a region of size between
>              10 and 20 [-Werror=format-truncation=]
>  1749 |        snprintf(tname, sizeof(tname), "process%d:thread%d", p, t);
>                                                                ^~
>  ...
>  bench/numa.c:1749:64: note: directive argument in the range
>                 [-2147483647, 2147483646]
>  ...
>  #
>
> The maximum length of the %d replacement is 11 characters because
> of the negative sign.  Therefore use %u as format conversion.

But their type is int and I'm afraid some compilers might complain
about it.  Why not just increase the buffer size?

Thanks,
Namhyung


>
> Output after:
>  # make  DEBUG=y bench/numa.o > /dev/null 2>&1; ll bench/numa.o
>  -rw-r--r-- 1 root root 418320 May 19 09:11 bench/numa.o
>  #
>
> Signed-off-by: Thomas Richter <tmricht@...ux.ibm.com>
> ---
>  tools/perf/bench/numa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
> index d5289fa58a4f..ff0bfd87afbb 100644
> --- a/tools/perf/bench/numa.c
> +++ b/tools/perf/bench/numa.c
> @@ -1746,7 +1746,7 @@ static int __bench_numa(const char *name)
>                         for (t = 0; t < g->p.nr_threads; t++) {
>                                 memset(tname, 0, sizeof(tname));
>                                 td = g->threads + p*g->p.nr_threads + t;
> -                               snprintf(tname, sizeof(tname), "process%d:thread%d", p, t);
> +                               snprintf(tname, sizeof(tname), "process%u:thread%u", p, t);
>                                 print_res(tname, td->speed_gbs,
>                                         "GB/sec",       "thread-speed", "GB/sec/thread speed");
>                                 print_res(tname, td->system_time_ns / NSEC_PER_SEC,
> --
> 2.36.1
>