rockchip-linux / rkdeveloptool

GNU General Public License v2.0
165 stars 96 forks source link

Fix format truncation for GCC >7.1. #62

Open phodina opened 2 years ago

phodina commented 2 years ago

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.

koftikes commented 2 years ago

Checked on Ubuntu 22.04 fix work correctly.

sprhawk commented 2 years ago

Haha, same issue, different method (https://github.com/rockchip-linux/rkdeveloptool/pull/63)

phodina commented 2 years ago

@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

orangecms commented 2 years ago

67 makes it even simpler :-)

edit: but looks unsage, see #57.

There are 5 patches here now all trying to fix this... :sweat_smile:

phodina commented 1 year ago

Doesn't matter which one just it gets fixed :-)