Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00570.html
On 10/8/19 5:51 PM, Martin Sebor wrote:
Attached is a resubmission of the -Wrestrict implementation for the sprintf family of functions. The original patch was posted in 2017 but never approved. This revision makes only a few minor changes to the original code, mostly necessitated by rebasing on the top of trunk. The description from the original posting still applies today: 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 subobject for struct members), and its size. For each %s argument, it then computes the same data. If it determines that overlap between the two is possible it stores the data for the directive argument (including the size of the argument) for later processing. After the whole call and format string have been processed, the code then iterates over the stored directives and their arguments and compares the size and length of the argument against the function's overall output. If they overlap it issues a warning. The solution is pretty simple. The only details that might be worth calling out are the addition of a few utility functions some of which at first glance look like they could be replaced by calls to existing utilities: * array_elt_at_offset * field_at_offset * get_origin_and_offset * alias_offset Specifically, get_origin_and_offset looks like a dead ringer for get_addr_base_and_unit_offset, except since the former is only used for warnings it is less conservative. It also works with SSA_NAMEs. This is also the function I expect to need to make changes to (and fix bugs in). The rest of the functions are general utilities that could perhaps be moved to tree.c at some point when there is a use for them elsewhere (I have some work in progress that might need at least one of them). Another likely question worth addressing is why the sprintf overlap detection isn't handled in gimple-ssa-warn-restrict.c. There is an opportunity for code sharing between the two "passes" but it will require some fairly intrusive changes to the latter. Those feel out of scope for the initial solution. Finally, because of new dependencies between existing classes in the file, some code had to be moved around within it a bit. That contributed to the size of the patch making the changes seem more extensive than they really are. Tested on x86_64-linux with Binutils/GDB and Glibc. Martin The original submission: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00036.html
