[PING #2] [PATCH] enhance -Wrestrict for sprintf %s arguments

[Martin Sebor]

Ping #2:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00036.html

> On 07/02/2017 02:00 PM, Martin Sebor wrote:
>> The attached patch enhances the -Wrestrict warning to detect more
>> than just trivial instances of overlapping copying by sprintf and
>> related functions.
>>
>> The meat of the patch is relatively simple but because it introduces
>> dependencies between existing classes in the sprintf pass I had to
>> move the class definitions around.  That makes the changes look more
>> extensive than they really are.
>>
>> The enhancement works by first determining the base object (or
>> pointer) from the destination of the sprintf call, the constant
>> offset into the object, and its size.  For each %s argument, it
>> then computes same information.  If it determines that overlap
>> between the two is possible it stores the information for the
>> directive argument (including the size of the argument) for later
>> processing.  After the whole call/format string has been processed,
>> the patch then iterates over the stored directives and their
>> arguments and compares the size/length of the argument against
>> the function's overall output.  If they overlap it issues
>> a warning.
>>
>> Tested on x86_64-linux.
>>
>> -Wrestrict is not currently included in either -Wextra or -Wall
>> and this patch doesn't change it even though there have been
>> requests to add it to one of these two options.  I'd like to do
>> that as a separate step.
>>
>> As the next step I'd also like to extend a limited form of the
>> -Wrestrict enhancement to other restrict-qualified built-ins (like
>> strcpy), and ultimately also to user-defined functions that make
>> use of restrict.  I think this might perhaps best be done in
>> a separate pass where the computed pointer information can be
>> cached to avoid recomputing it for each call, but I don't expect
>> to be able to have the new pass (or whatever form the enhancement
>> might end up taking) to also handle sprintf (at least not with
>> the same accuracy it does now) because the sprintf data for each
>> format directive are not available outside the sprintf pass.
>>
>> Martin
>