Re: Fwd: format-truncation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
>
> Martin
>
> [*] To be clear: the warning assumes POSIX conformance here.  GCC
> optimizations only assume C conformance.
>



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux