On Thu, 14 Feb 2019 at 20:18, Kalamatee <kalamatee@xxxxxxxxx> wrote: > Thanks for clarifying - I will look into what you have suggested. > > On Thu, 14 Feb 2019 at 20:16, Martin Sebor <msebor@xxxxxxxxx> wrote: > >> On 2/14/19 3:41 AM, Kalamatee wrote: >> > ---------- Forwarded message --------- >> > From: Kalamatee <kalamatee@xxxxxxxxx> >> > Date: Thu, 14 Feb 2019 at 10:35 >> > Subject: Re: format-truncation >> > To: Jonathan Wakely <jwakely.gcc@xxxxxxxxx> >> > >> > >> > >> > >> > On Thu, 14 Feb 2019 at 10:27, Kalamatee <kalamatee@xxxxxxxxx> wrote: >> > >> >> >> >> >> >> On Thu, 14 Feb 2019 at 10:19, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> >> >> wrote: >> >> >> >>> On Thu, 14 Feb 2019 at 10:11, Kalamatee <kalamatee@xxxxxxxxx> wrote: >> >>>> >> >>>> Hello >> >>>> >> >>>> I am having trouble identifying how to fix the following error we >> >>> encounter >> >>>> when compiling AROS using our patched gcc 8.2. >> >>>> >> >>>> Compile failed: ccache >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/linux-x86_64/tools/crosstools/x86_64-aros-gcc >> >>>> -iquote >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/components/utilities/ >> >>>> -iquote /mnt/c/Users/kalam/AROS/svn-repo/AROS/arch/all-pc/acpica >> >>> -iquote . >> >>>> -mcmodel=large -mno-red-zone -mno-ms-bitfields -O2 >> >>>> -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -Wall -Werror >> >>>> -Wno-pointer-sign -Wno-parentheses -Wno-strict-aliasing >> >>>> >> >>> >> -I/home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/AROS/Developer/include/acpica >> >>>> -iquote >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/include >> >>>> -iquote >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/include/platform >> >>>> -DAROS_BUILD_TYPE=AROS_BUILD_TYPE_PERSONAL >> >>>> >> >>> >> -I/home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/gen/arch/all-pc/acpica/acpica/include >> >>>> -include >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/gen/arch/all-pc/acpica/acpica/include/acpica_deflibdefs.h >> >>>> >> >>> >> -D__SRCFILENAME__="bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/components/utilities/utprint.c" >> >>>> -c >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/components/utilities/utprint.c >> >>>> -o >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/gen/arch/all-pc/acpica/acpica/utprint.o >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/components/utilities/utprint.c: >> >>>> In function 'sprintf': >> >>>> >> >>> >> /home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/Ports/acpica/acpica-unix-20190108/source/components/utilities/utprint.c:880:14: >> >>>> error: specified bound 4294967295 exceeds 'INT_MAX' >> >>>> [-Werror=format-truncation=] >> >>>> Length = vsnprintf (String, ACPI_UINT32_MAX, Format, Args); >> >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >>>> cc1: all warnings being treated as errors >> >>>> mmakefile:918: recipe for target >> >>>> >> >>> >> '/home/nick/builds/pc-x86_64-smp-gcc8/bin/pc-x86_64-smp/gen/arch/all-pc/acpica/acpica/utprint.o' >> >>>> failed >> >>>> >> >>>> My problem is I cannot see where it is getting "INT_MAX" from as the >> >>> bounds >> >>>> for the 2nd parameter. >> >>>> >> >>>> The documentation for vsnprintf says "If the *maxlen* value is 0, no >> >>>> characters are written, and *vsnprintf* returns 0. If the value is >> >>> greater >> >>>> than *INT_MAX* , then *vsnprintf* behaves identically to *vsprintf* >> in >> >>> that >> >>> >> >>> Isn't that where it's coming from? >> >>> >> >>> The warning is telling you that the output could be unchecked, e.g. if >> >>> it writes UINT32_MAX+1 then it would overflow your buffer. >> >>> >> >> >> >> That's not what the warning/error is saying? It says ACPI_UNIT32_MAX >> >> exceeds INT_MAX. It seems a bit misleading/confusing when it is valid >> for >> >> the second parameter to take values over INT_MAX. >> >> >> >> >> > My point is - if it generated a warning/error for "UNIT32_MAX + 1" that >> > _would_ be acceptable - but UNIT32_MAX itself is a constant and it can >> see >> > at compile time that can not over flow the buffer. >> >> snprintf (and vsnprintf) are required by POSIX to fail when the value >> of n is greater than INT_MAX. Not all implementations conform to this >> requirement, but calling snprintf with a size in excess of INT_MAX is >> pointless even on implementations that don't fail because the function's >> behavior is undefined if the amount of its output exceeds INT_MAX. When >> there is no limit sprintf should be used instead. >> >> That said, the code you pointed to looks like an implementation of >> sprintf (and vsnprintf). Unless that implementation conforms to C >> and POSIX some instances of the warning will probably not make sense. >> Not only that, the code GCC will emit may not make sense because it >> assumes a conforming C implementation(*). So if that's the case >> (i.e., if the implementation doesn't conform to C) you should prevent >> GCC from assuming it does by -fno-builtin=snprintf. >> >> I suspect you made a typo but regardless; -fno-builtin-vsnprintf does suppress the warning, so thanks again for the pointer. > Martin >> >> [*] To be clear: the warning assumes POSIX conformance here. GCC >> optimizations only assume C conformance. >> >
