This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: -Wstrict-aliasing extension (Mark Mitchell)  wrote on 08.03.04 in <>:

> 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  
fundamentally broken.

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.

MfG Kai

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]