On 07/10/2017 05:27 PM, Joseph Myers wrote:
On Mon, 10 Jul 2017, Martin Sebor wrote:
On 07/07/2017 10:58 AM, Joseph Myers wrote:
This patch is OK.
Thanks. Committed in r250104.
Do you have any comments on or concerns with changing how
LangEnabledBy interprets the opt argument as I suggested below?
IMO, it makes little sense for an option that takes an argument
and that specifies a binary option like -Wall in LangEnabledBy
to default to the binary value of the latter option. I think
it would be more intuitive and convenient for it to default to
the value set by its Init directive for the positive form of
the binary option and to zero for the negative form (or to empty
for strings, if that's ever done).
I'm uneasy about the notion of -Wall implying an option that's
on-by-default at all. If it's on-by-default, why should -Wall have
anything to do with it? (Resetting from 2 to 1 is obviously wrong.)
Such an implication only makes sense to me if -Wall implies a *different*
(presumably higher) value than the default. And in the case of Init(-1)
(for special logic to initialize an option), copying the Init value
certainly doesn't make sense in an implication.
That sounds like a good point for -Wstringop-verflow. I think
there I copied the whole LangEnabledBy attribute from another
option without fully considering (or even understanding) its
effect. I'm pretty sure copying options like this is uncommon,
and what I'd like to do is help avoid similar kinds of mistake
in the future. This is one small tweak that can help. Better
checking of the attributes for consistency and sanity would be
another, provided "boolean to integer conversions" were treated
as invalid by the option scripts. The checking could also reject
the mistake of redundantly specifying -Wall for an option that's
on by default (or worse, having -Wall or -Wextra lower a numeric
option's default argument value).
Martin