This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)
Hi Martin,
> On 09/22/2016 06:14 AM, Rainer Orth wrote:
>> Hi Martin,
>>
>>> your patch broke bootstrap with MPFR 2.4.2, which is still the
>>> recommended (or perhaps minimal) version according to install.texi:
>> [...]
>>> The following patch (together with your other one to fix ILP32 targets)
>>> allows a sparc-sun-solaris2.12 bootstrap to continue. I'm going to
>>> commit it as obvious.
>>
>> done now. Once the bootstrap had finished, I see quite a number of
>> testsuite failures (i386-pc-solaris2.12 still running), both 32 and
>> 64-bit:
>>
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1220)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1270)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line
>> 1381)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 356)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 99)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
>
> I have a patch for (hopefully) most of these failures that I will
> commit along with the one for pr77676 as soon as it's approved.
as of r240389, a few of those failures occur also on x86_64-pc-linux-gnu
with -m32:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1222)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1272)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1383)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
>> +FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
>>
>> FAIL: test_a_double:364: "%a" expected result for "0x0.0000000000000p+0"
>> doesn't match function call return value: 20 != 6
>> FAIL: test_a_double:365: "%a" expected result for "0x1.0000000000000p+0"
>> doesn't match function call return value: 20 != 6
>> FAIL: test_a_double:366: "%a" expected result for "0x1.0000000000000p+1"
>> doesn't match function call return value: 20 != 6
>>
>> FAIL: test_a_long_double:375: "%La" expected result for
>> "0x0.0000000000000000000000000000p+0" doesn't match function call return
>> value: 35 != 6
>> FAIL: test_a_long_double:376: "%La" expected result for
>> "0x1.0000000000000000000000000000p+0" doesn't match function call return
>> value: 35 != 6
>> FAIL: test_a_long_double:377: "%La" expected result for
>> "0x1.0000000000000000000000000000p+1" doesn't match function call return
>> value: 35 != 6
>
> I don't know about these. It looks like the Solaris printf doesn't
> handle the %a directive correctly and the tests (and the related
> checks/optimization) might need to be disabled, which in turn might
> involve extending the existing printf hook or adding a new one.
I've found the following in Solaris 10 (and up) printf(3C):
a, A A double argument representing a floating-point
number is converted in the style "[-]0xh.hhhhp+d",
where the single hexadecimal digit preceding the
radix point is 0 if the value converted is zero and
1 otherwise and the number of hexadecimal digits
after it is equal to the precision; if the precision
is missing, the number of digits printed after the
radix point is 13 for the conversion of a double
value, 16 for the conversion of a long double value
on x86, and 28 for the conversion of a long double
value on SPARC; if the precision is zero and the '#'
flag is not specified, no decimal-point character
will appear. The letters "abcdef" are used for a
conversion and the letters "ABCDEF" for A conver-
sion. The A conversion specifier produces a number
with 'X' and 'P' instead of 'x' and 'p'. The
exponent will always contain at least one digit, and
only as many more digits as necessary to represent
the decimal exponent of 2. If the value is zero, the
exponent is zero.
The converted value is rounded to fit the specified
output format according to the prevailing floating
point rounding direction mode. If the conversion is
not exact, an inexact exception is raised.
A double argument representing an infinity or NaN is
converted in the SUSv3 style of an e or E conversion
specifier.
I tried to check the relevant sections of the latest C99 and C11 drafts
to check if this handling of missing precision is allowed by the
standard, but I couldn't even fully parse the language there.
> I don't have access to Solaris to fully debug and test this there.
> Would you mind helping with it?
Not at all: if it turns out that Solaris has bugs in this area, I can
easily file them, too.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University