Re: Wmissing-base-class-initializer (PR7651 Define -Wextra strictly in terms of other warning flags)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Manuel López-Ibáñez" <lopezibanez@gmail.com> writes:


[...]

| > -Wextra should be split into *logical* subsets.  I fully appreciate
| > the task is hard, but if we review only one option at a time, we may
| > very well miss the picture and end up leaking implementation detail
| > information.
| 
| I completely agree. I am trying to do this, so if you could point to
| logical subsets, I will happily fix the patches. Still, I think it
| would be easier to see the relations once Wextra is completely cleaned
| up.

so, once we have checked in zillions of option names, we would
have seen the design; that is where I'm trying not to get at.  I would
like to see a general idea of the design first.  Once,
something is in, it tends to be difficult to get it out.

| There is still a lot of time before GCC 4.3 is released 

I have been there before :-)

[...]

| What I don't want is to incorporate a controversial and hard to avoid
| warning from Wextra (such as an unsigned value is compared against
| zero with < or >=) into a generally useful and appreciated warning
| such as Walways-true that is enabled by Wall. Given the description of
| Walways-true, it may *logically* make sense but from the perspective
| of our users it would be a disaster.

if the documentation logically makes sense but the implementation does
not match the logical description, then we have a problem with the
logical description and or the implementation.  Beause the effect is
that user would read the documentation but be surprised by the
result.  It also means that we don't have a relatievely predictable
interface unless we know the implementation.

| > One way to do that is that we have a summary of the kind
| > of messages currently controlled by -Wextra.
| 
| I don't get this.

grep warn_extra; make a "digest".

-- Gaby