[PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 10/05/2016 05:11 PM, Joseph Myers wrote:
> On Wed, 5 Oct 2016, Martin Sebor wrote:
>
>> may have been subjected to.  Issuing a warning for a safe piece
>> of code only on the basis that there might be some other piece
>> of code in the program that does something wrong makes no sense.
>> Suggesting to the user to change the safe piece of code is
>> misleading and counterproductive.
>
> It's warning because it's *bad code*.

Why?  What can go wrong and on what system?  Please name at least
one specific example.

> Whether it's safe or not is
> peripheral.  Lots of warnings are for things that are dubious even if they
> may happen to do what the user wants on the platforms they care about.
> I'd consider even cases of different signedness (e.g. passing one of int
> and unsigned int to a format expecting the other) to be dubious without a
> reason why values not representable in the other type can't reach that
> code - and I'd consider cases where the types are different not just in
> signedness to be clearly worse than the cases that we only warn for with
> -Wformat-signedness.
>
>>> There are plenty of architectures where the ABI does require the high part
>>> to be extended in a particular way;
>>
>> There is no high part when the wchar_t and wint_t types have
>> the same size, which they do not only in the case of interest but
>
> I mean high parts if the ABI is passing those arguments in 64-bit
> registers / stack slots and has requirements on how 32-bit arguments are
> extended for passing as 64-bit.

I don't understand what you mean.  We're talking about passing
an integer (wchar_t) via the ellipsis.  That's just as well
defined as passing any other integer of that size, as is (for
all practical purposes) extracting it via an integer of the
opposite signedness.  printf then stuffs the extracted wint_t
value (which is of the same size as the original wchar_t) into
a wchar_t, appends a nul, and formats the result via %ls (at
least that's how it's specified).

Please explain what can go wrong on i386 when someone calls
printf("%lc", L'a'), or on any other target GCC supports.
I will be happy to agree that the warning is justified if
you show me how this breaks and where.

Martin