On 11/17/20 7:09 PM, Martin Sebor wrote:
> On 11/16/20 4:54 PM, Jeff Law wrote:
>>
>> On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
>>> On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>> GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
>>>> so that the difference between a pointer to the byte just past its
>>>> end and the first one is no more than PTRDIFF_MAX. This is too
>>>> liberal in LP64 on most systems because the size of the address
>>>> space is constrained to much less than that, both by the width
>>>> of the address bus for physical memory and by the practical
>>>> limitations of disk sizes for swap files.
>>> Shouldn't this be a target hook like MAX_OFILE_ALIGNMENT then?
>>
>> I think one could argue either way. Yes, the absolutes are a function
>> of the underlying hardware and it can change over the lifetime of a
>> processor family which likey differs from MAX_OFILE_ALIGNMENT.
>>
>>
>> A PARAM gives the developer a way to specify the limit which is more
>> flexible.
>>
>>
>> What I'm not really not sure of is whether is really matters in practice
>> for end users.
>
> I'd like to do two things with this change: 1) make it easier
> (and encourage users) to detect as early as possible more bugs
> due to excessive sizes in various function calls (malloc, memcpy,
> etc.), and 2) verify that GCC code uses the limit consistently
> and correctly.
>
> I envision the first would appeal to security-minded distros
> and other organizations that use GCC as their system compiler.
> For those, a target hook would be more convenient than a --param.
> But I also expect individual projects wanting to impose stricter
> limits than distros select. For those, a --param is the only
> choice (aside from individual -Wlarger-than- options(*)).
>
> With this in mind, I think providing both a target hook and
> a --param has the best chance of achieving these goals.
>
> The attached patch does that.
>
> Martin
>
> [*] To enforce more realistic object size limits than PTRDIFF_MAX,
> GCC users today have to set no fewer than five (or six if we count
> -Wstack-usage) options: -Walloca-larger-than,
> -Walloc-size-larger-than, -Wframe-larger-than, -Wlarger-than, and
> -Wvla-larger-than. The limits are all independent of one another.
> I expect providing a single configurable baseline value for all
> these options to use and refine to be helpful to these users.
>
> gcc-max-objsize.diff
>
The more I think about this, the more I think it's not really useful in
practice.
I don't see distros using this flag as there's likely no good values a
distro could use that would likely catch bogus code without needlessly
flagging valid code.
I don't see individual projects using this code either -- for the most
part I would not expect a project developer to be able to accurately
predict the maximum size of allocations they potentially perform and
then bake that into their build system. There are exceptions (kernel &
embedded systems come immediately to mind).
And finally, I'm really not a fan of --params for end-user needs. Those
feel much more like options that we as GCC developers use to help
ourselves rather than something we encourage others to use.
Jeff
