[PATCH] Improve -Wmaybe-uninitialized documentation

Jonathan Wakely jwakely@redhat.com
Fri Nov 17 12:56:00 GMT 2017


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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2078 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20171117/b3db86fa/attachment.bin>


More information about the Gcc-patches mailing list