rkdeveloptool
rkdeveloptool copied to clipboard
Fix format truncation for GCC >7.1.
Hi,
I'm trying to build the project but there seems to be error
make[1]: Entering directory '/tmp/guix-build-rkdeveloptool-1.32-1.46bb4c0.drv-0/source'
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT crc.o -MD -MP -MF .deps/crc.Tpo -c -o crc.o crc.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKBoot.o -MD -MP -MF .deps/RKBoot.Tpo -c -o RKBoot.o RKBoot.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKComm.o -MD -MP -MF .deps/RKComm.Tpo -c -o RKComm.o RKComm.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKDevice.o -MD -MP -MF .deps/RKDevice.Tpo -c -o RKDevice.o RKDevice.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKImage.o -MD -MP -MF .deps/RKImage.Tpo -c -o RKImage.o RKImage.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKLog.o -MD -MP -MF .deps/RKLog.Tpo -c -o RKLog.o RKLog.cpp
g++ -DHAVE_CONFIG_H -I. -I./cfg -Wall -Werror -Wextra -Wreturn-type -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -I/gnu/store/vjlg2z75qwbwxdp5qiklcdx7df9xvbb2-libusb-1.0.24/include/libusb-1.0 -g -O2 -MT RKScan.o -MD -MP -MF .deps/RKScan.Tpo -c -o RKScan.o RKScan.cpp
mv -f .deps/RKBoot.Tpo .deps/RKBoot.Po
mv -f .deps/RKImage.Tpo .deps/RKImage.Po
mv -f .deps/crc.Tpo .deps/crc.Po
mv -f .deps/RKLog.Tpo .deps/RKLog.Po
mv -f .deps/RKComm.Tpo .deps/RKComm.Po
mv -f .deps/RKDevice.Tpo .deps/RKDevice.Po
mv -f .deps/RKScan.Tpo .deps/RKScan.Po
main.cpp: In function ?bool _Z9mergeBootv.part.0()?:
main.cpp:1493:36: error: ?%s? directive output may be truncated writing up to 557 bytes into a region of size 5 [-Werror=format-truncation=]
1493 | snprintf(buffer, sizeof(buffer), "%s", chip);
| ^~
......
1534 | chipType = convertChipType(chip + 2);
| ~~~~~~~~~~~~~~~~~~~~~~~~~
main.cpp:1493:10: note: ?snprintf? output between 1 and 558 bytes into a destination of size 5
1493 | snprintf(buffer, sizeof(buffer), "%s", chip);
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:490: main.o] Error 1
make[1]: Leaving directory '/tmp/guix-build-rkdeveloptool-1.32-1.46bb4c0.drv-0/source'
make: *** [Makefile:510: all-recursive] Error 1
You seem to rely on implicit truncation instead of explicitly truncating the string. This patch fixes the issue with GCC. It's not nice but working with strings in C is a mess.
Checked on Ubuntu 22.04 fix work correctly.
Haha, same issue, different method (https://github.com/rockchip-linux/rkdeveloptool/pull/63)
@sprhawk you're fix seem from the technical stand point of view more correct. But both accomplish the same :-)
Though I'm not sure what's the standpoint on #pragma
and if it's also possible solution for other compilers e.g. LLVM
#67 makes it even simpler :-)
edit: but looks unsage, see #57.
There are 5 patches here now all trying to fix this... :sweat_smile:
Doesn't matter which one just it gets fixed :-)