Fwd: format-truncation

Martin Sebor msebor@gmail.com
Thu Feb 14 20:16:00 GMT 2019


On 2/14/19 3:41 AM, Kalamatee wrote:
> ---------- Forwarded message ---------
> From: Kalamatee <kalamatee@gmail.com>
> Date: Thu, 14 Feb 2019 at 10:35
> Subject: Re: format-truncation
> To: Jonathan Wakely <jwakely.gcc@gmail.com>
> 
> 
> 
> 
> On Thu, 14 Feb 2019 at 10:27, Kalamatee <kalamatee@gmail.com> wrote:
> 
>>
>>
>> On Thu, 14 Feb 2019 at 10:19, Jonathan Wakely <jwakely.gcc@gmail.com>
>> wrote:
>>
>>> On Thu, 14 Feb 2019 at 10:11, Kalamatee <kalamatee@gmail.com> 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.



More information about the Gcc-help mailing list