On 10/23/24 14:30, Richard Henderson wrote:
On 10/23/24 13:15, Pierrick Bouvier wrote:
On 10/23/24 12:50, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
Simply increase destination buffer size so truncation can't happen.
"cc" "-m64" "-Ilibcommon.a.p" "-Isubprojects/dtc/libfdt"
"-I../subprojects/dtc/libfdt"
"-ID:/a/_temp/msys64/mingw64/include/pixman-1"
"-ID:/a/_temp/msys64/mingw64/include/glib-2.0"
"-ID:/a/_temp/msys64/mingw64/lib/glib-2.0/include"
"-ID:/a/_temp/msys64/mingw64/include/ncursesw"
"-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Werror"
"-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wempty-body"
"-Wendif-labels" "-Wexpansion-to-defined" "-Wformat-security"
"-Wformat-y2k" "-Wignored-qualifiers" "-Wimplicit-fallthrough=2"
"-Winit-self" "-Wmissing-format-attribute" "-Wmissing-prototypes"
"-Wnested-externs" "-Wold-style-declaration" "-Wold-style-definition"
"-Wredundant-decls" "-Wshadow=local" "-Wstrict-prototypes"
"-Wtype-limits" "-Wundef" "-Wvla" "-Wwrite-strings"
"-Wno-missing-include-dirs" "-Wno-psabi" "-Wno-shift-negative-value"
"-iquote" "." "-iquote" "D:/a/qemu/qemu" "-iquote"
"D:/a/qemu/qemu/include" "-iquote"
"D:/a/qemu/qemu/host/include/x86_64" "-iquote"
"D:/a/qemu/qemu/host/include/generic" "-iq
../net/tap-win32.c: In function 'tap_win32_open':
../net/tap-win32.c:343:19: error: '%s' directive output may be truncated
writing up to
255 bytes into a region of size 176 [-Werror=format-truncation=]
343 | "%s\\%s\\Connection",
| ^~
344 | NETWORK_CONNECTIONS_KEY, enum_name);
| ~~~~~~~~~
In function 'get_device_guid',
inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10:
../net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347
bytes into a destination of size 256
Is the compiler min/max maxing what UCS-16 or UTF-8 might pack into that string?
Yes, enum_name (used to compose final string) is already sized 256, so result
*may* be
bigger. I'm not sure it would happen in the real world though.
There are several patches for this, most recently:
https://lore.kernel.org/qemu-devel/20241008202842.4478-1-shen...@gmail.com/
r~
Thanks for pointing it Richard.
The linked patch is better than current approach, so it should be favored.
Regards,
Pierrick
