tools/perf/bench/numa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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.
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@linux.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
On Thu, May 19, 2022 at 9:27 AM Thomas Richter <tmricht@linux.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@linux.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
>
On 5/19/22 23:45, Namhyung Kim wrote: > On Thu, May 19, 2022 at 9:27 AM Thomas Richter <tmricht@linux.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 > > Sure fine with me, I will send v2 and increase the array size. Thanks -- Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany -- Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
© 2016 - 2026 Red Hat, Inc.