On 10 Jan 2007 05:47:19 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
Chris Pickett <[EMAIL PROTECTED]> writes:
| 1.  Create a default section, at the top, and put all options enabled
| by default there.
|
| 2.  Try to group options so that they are closer to other connected
| nodes in the graph.
| 3.  Get rid of the -Wno-xxx option listings, since it is not always
| the case that -Wxxx is enabled by "default", and this just ends up
| being rather confusing.  Instead, explain in the default section that
| everything there can be disabled with -Wno-xxx.
Actually, I would put first a general paragraph: explaining that any
-W* is a warning option, any W* option can be disabled, what is Werror
and -w.

After that, I would start listing options. First, a default section
with just names, then pedantic, -fsyntax-only and similar (special
options). Then, Wall and Wextra and other super-options but just
listing which warnings they activate.

Finally, a ordered list (perhaps divided in different sections for
each language) of all warning options with their descriptions and a
short sentence saying which super-options enable it or whether it is
enabled by default.

I assume the -Wno-xxx that are set by default would be moved to the
"default" section?

No. Warnings that are not active by default are obviously disabled,
there is no need to mention them. Actually, we should be more specific
saying that using Wno-* disables a warning no matter what you put on
the commandline, so, strictly speaking, it is false that warnings that
are not enabled by default are equivalent to -Wno-*



| # A <-- B && C   option A is implied by options B and C together
Do you have an example of this?


| # A --> B        option A implies option B
| # A ==> B        option A enables option B
What is the difference between "implies" and "enables" ?

| default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar
|             -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of
|             -Wint-to-pointer-cast -Wpointer-to-int-cast

plus others that are not controlled by named flags.
Should all warnings be controlled by some or other flag?

| -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign

plus others that are not controlled by named flags.
It is not obvious
whether some of the warning should become hard errors or stay pedwarns as
some of the pedwarns were introduced as transitional paths logn time ago.

Yes, pedantic also needs a cleanup but that is going to be tough

| -pedantic <-- -pedantic-errors

-ansi (and corresponding -std= options) also implies pedwarns or
errors but not all.
Moreoverm, g++ -fpermissive issues warnings where it should be
issueing hard errors.

Why pedantic issues warnings in C and errors in C++ and fpermissive
converts the errors back to warnings? This is something that has
always confused me.

[...]

| -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s)

I believe the correct understanding is that it depends on optimization
level different from -O0.

It seems to me that the only reason for Winit-self to exists is that
people try to silence the -Wuninitialized warnings using the init-self
hack and then other people have to work-around that hack. Really sad
and one of the culprits is the deficiencies in -Wuninitialized itself.
Perhaps we should divide -Wuninitialized into -Wuninitialized-sure and
-Wuninitialized-may.

| -Wimplicit <-- -Wall # redundant implication

Hmm, I don't understand what you mean here.

Me neither. Also, you missed -Werror-implicit-function-declaration
which is a weird and useless option. I have to investigate its
history.

| -W --> -Wextra

We would like "-W" not to be mentioned anymore.

Yes, sometimes is better to forget somethings...

Manuel.

Reply via email to