On 11/17/2017 05:40 AM, Jonathan Wakely wrote:
> On 16/11/17 09:18 -0700, Martin Sebor wrote:
>> On 11/16/2017 03:49 AM, Jonathan Wakely wrote:
>>> On 15/11/17 20:28 -0700, Martin Sebor wrote:
>>>> On 11/15/2017 07:31 AM, Jonathan Wakely wrote:
>>>>> The docs for -Wmaybe-uninitialized have some issues:
>>>>>
>>>>> - That first sentence is looooooong.
>>>>> - Apparently some C++ programmers think "automatic variable" means one
>>>>> declared with C++11 `auto`, rather than simply a local variable.
>>>>> - The sentence about only warning when optimizing is stuck in between
>>>>> two chunks talking about longjmp, which could be inferred to mean
>>>>> only the setjmp/longjmp part of the warning depends on optimization.
>>>>>
>>>>> This attempts to make it easier to parse and understand.
>>>>
>>>> I've always found the description remarkably precise. Particularly
>>>> the bit where it talks about the two paths, one initialized and the
>>>> other not. Your rewording loses that distinction so I don't think
>>>> it's as accurate, or even correct.
>>>>
>>>> To use an example, this would satisfy the new description:
>>>>
>>>> int f (void)
>>>> {
>>>> int i;
>>>> return i;
>>>> }
>>>>
>>>> but it doesn't match GCC behavior (it triggers -Wuninitialized,
>>>> not -Wmaybe-uninitialized). Unless the distinction is more
>>>> subtle than I ascribe to it I think it needs to be preserved
>>>> in the rewording.
>>>
>>> Ah, I tested a similar case and missed that the warning I got was from
>>> -Wuninitialized not -Wmaybe-uninitialized, which made me think that
>>> "a use of the variable that is initialized" was wrong.
>>>
>>> OK, so then here's an alternative patch which doesn't touch that first
>>> sentence except to add "(i.e. local)". That makes the first sentence
>>> even longer, but if it's accurate maybe that's OK. This still adds
>>> "These warnings are only possible in optimizing compilation, because
>>> otherwise GCC does not keep track of the state of variables." And
>>> removes the similar text from the middle of the setjmp/longjmp
>>> discussion.
>>
>> Thanks, this looks fine to me.
>>
>> As an aside, I wonder if you think that rewording the part about
>> GCC not being smart enough might be worthwhile:
>>
>> These warnings are made optional because GCC is not smart enough
>> to see all the reasons why the code might be correct in spite of
>> appearing to have an error.
>>
>> It sounds just a little pejorative (or maybe just colloquial) to
>> me for the manual. Perhaps:
>>
>> These warnings are made optional because GCC may not be able to
>> determine when the code is correct in spite of appearing to have
>> an error.
>
> I think that's an improvement. New patch attached.
>
> Jeff, is this still OK?
Yes.
jeff
