On 11/18/2017 09:47 AM, Martin Sebor wrote: > On 11/18/2017 12:53 AM, Jeff Law wrote: >> On 11/17/2017 12:36 PM, Martin Sebor wrote: >>> The attached patch enhances -Wstringop-overflow to detect more >>> instances of buffer overflow at compile time by handling non- >>> constant offsets into the destination object that are known to >>> be in some range. The solution could be improved by handling >>> even more cases (e.g., anti-ranges or offsets relative to >>> pointers beyond the beginning of an object) but it's a start. > > I should have made it even more clear that this change affects > just warnings, not the runtime protection with _FORTIFY_SOURCE. > The latter is driven by the __builtin_object_size intrinsic and > by the compute_builtin_object_size GCC function. > > This patch does not change what __builtin_object_size returns. Understood. But I think that the documented behavior of b_o_s directly impacts how this routine is supposed to work.
>> > -Wstringop-overflow (i.e., warnings only) always uses the largest > object size for memxxx functions (type 0) and the smallest (type > 2) for string functions by default. This can be changed but I > suspect no one does because (IME) few users understand what > the other modes mean or what good using them vs the default might > do. It was probably a mistake to expose the mode via the option. Then maybe only do the deeper analysis for max mode only? As it stands if someone were to call it in a min mode I think they're going to be rather surprised by the answer. jeff
