This is the mail archive of the
mailing list for the GCC project.
Re: RFC: -Wstrict-aliasing extension
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc-patches at gcc dot gnu dot org
- Date: 12 Mar 2004 21:54:00 +0200
- Subject: Re: RFC: -Wstrict-aliasing extension
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <firstname.lastname@example.org> <email@example.com> <404CE496.firstname.lastname@example.org>
email@example.com (Mark Mitchell) wrote on 08.03.04 in <404CE496.firstname.lastname@example.org>:
> I'm also disinclined towards adding more warning options, since I think
> it's already gotten very confusing for users. Unless we're willing to
> go to the model where you have a list of error messages in a book, with
> numbers/names, so that people can look them up easily and turn on/off
> subsets of them. I think right now we add lots of command-line options
> because that's easier than figuring out how to get warning groups that
> really work well for people, and then our cleverest users figure out how
> to get just what they want, but sometimes the less dedicated users
> compare us unfavorably to the competition. On the other hand, since
> this is definitely our existing practice and the warning could be useful
> to some people, if you added it as a separate warning, I wouldn't object.
I just recently tuned (2.95 objc) warnings for a project that I wanted to
put under -Werror as I didn't notice critical warnings once too often.
>From that experience, I'll say that I *hate hate hate* warnings that can
only be switched on or off via a warning group.
I definitely want more warning options, not less - the finer grained the
There's nothing wrong with warning groups *if* you can split them up again
when necessary. If that is not possible, I'd much rather have *no* warning
Warning groups that can't be split up don't work well period.
The idea that certain warnings are always all on or all off is
For example, for the above-mentioned project, I need to live without any
of the warnings in -W because one or two of them cannot be reasonably
worked around, and cannot separately be switched off either - nor can the
others be separately switched on.
Even some of the options gcc thinks of as non-group are still not
finegrained enough, because they do trigger significantly different
warnings - though I can't give an example from memory.
You say that
> and then our cleverest users figure out how
> to get just what they want,
- well, I have repeatedly hit a wall where the only way to get what I want
would have been a patch to make gcc warnings more fine-grained.