[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

--- Comment #27 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #26)
> (In reply to Manuel López-Ibáñez from comment #25)
> > I don't see any reason for -Wuninitialized to not enable
> > -Wmaybe-uninitialized.
> 
> I can see 3 kinds of use:
> 
> 1. Users who are interested in neither: they just don't use these options
> (if they want to use -Wall, they need the -Wno- version).

-Wall -Wno-uninitialized suppresses both.


> 2. Users interested in -Wuninitialized but not in -Wmaybe-uninitialized (to
> avoid potential many false positives). Because -Wuninitialized enables
> -Wmaybe-uninitialized, they need 2 options: -Wuninitialized
> -Wno-maybe-uninitialized. If -Wuninitialized did not enable
> -Wmaybe-uninitialized, only one option would be needed: -Wuninitialized.

This argument goes both ways: if you are interested in both warnings, you would
need both options.

> 3. Users interested in both. I think that -Wmaybe-uninitialized should
> enable -Wuninitialized because it makes no sense to have
> -Wmaybe-uninitialized but not -Wuninitialized. Indeed, if some variable is
> uninitialized, then it may be uninitialized. So, only one option should be
> needed in this case: -Wmaybe-uninitialized.

Aha! This is a really good point on which I can agree. However, it will
seriously break backwards compatibility for people that use either
-Wuninitialized or -Wno-uninitialized explicitly. I am not sure if the pain is
worth the beauty.

I don't think it is worth to discuss this in Bugzilla (specially not on this
PR). If you are convinced that this is the right thing to do, you could propose
a patch to gcc-patches and see how people receive it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply to: