Sorry - but I replied to the message. I didn't check to see if you have emailed privately instead of continuing the discussion on the mailing list I posted to. On Thu, 14 Feb 2019 at 10:39, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > I've just noticed this reply was off-list. Please reply to the list, > not just to me. I'm not interested in discussing this in private. > > On Thu, 14 Feb 2019 at 10:38, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> > wrote: > > > > 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. > > > > Which means you are (potentially) writing more than INT_MAX, which > > means the output might not be checked for overflowing the buffer. > > > > >It seems a bit misleading/confusing when it is valid for the second > parameter to take values over INT_MAX. > > > > It's valid, but may lead to undefined behaviour because there's no > > checking. If you don't want an error for that, don't use > > -Werror=format-truncation. > > > > > > > > I'm aware I can disable the diagnostic - but I don't like turning them > off for one function (when that may hide other functions with real issues), > but I guess there is no other option to stop this? > > > >
