On 06/07/2018 04:40 PM, Jakub Jelinek wrote:
On Thu, Jun 07, 2018 at 04:11:25PM -0600, Martin Sebor wrote:
Also, the option is not documented in doc/invoke.texi, it is just mentioned
in description of the -Walloc-size-larger-than= option, that is not enough;
it needs to be listed in the Warning Options list, and it should have
@itemx next to -Walloc-size-larger-than=.
Adding @itemx will just add a index entry for it, right? That
makes sense.
I'm not sure I agree that the negative form should be listed
in @gccoptlist{}. Only options that are on by default mention
the -Wno- form there so including both forms would go against
this convention.
If an option only has a no form, it should be listed too of course.
@item is not index, that is @opindex, which is missing for
Walloc-size-larger-than= too.
I'm not convinced backporting the addition of the new options to release
branches is desirable, fixing the bug in alloc_max_size is ok for the
branches.
I agree. (Or did you mean to include -Wno-alloc-size-larger-than
among the new options?)
I mean all these new -Wno-* options, including
-Wno-alloc-size-larger-than. That is not a bugfix, but a new feature.
Strictly speaking (from an implementer's POV), yes. But from
a user's POV, it's the first thing people try to use to disable
the warning -- see comments #1 and #2 on bug 85783. The other
mechanisms are much less intuitive: specifying a huge value is
not intuitive likely because in all other contexts an option
argument greater than INT_MAX wraps around zero, and using zero
doesn't work by design (it's a request to warn on all non-zero
allocations). It's trivially safe to make it work so it seems
there ought to be some flexibility in the policy in the interest
of user friendliness. Reconsider -Wno-alloc-size-larger-than?
Martin
