[PURRS-devel] Re: One last time: annoying warning

Gabriel Dos Reis gdr at integrable-solutions.net
Sun Sep 29 10:19:24 CEST 2002


Roberto Bagnara <bagnara at cs.unipr.it> writes:

[...]

| > Given the tone you're taking
| 
| Tone?  Which tone?  I am simply defending a point of view that I
| believe is quite reasonable.

Telling people they are irrespectful to users, when it is a matter of
style isn't something I consider "reasonable" for any reasonable
definition of "reasonable.

[...]

|  > and the lack of recognizing actual facst,
| 
| Facts?  Which facts?  I was offered no facts: you and others have
| simply stated that your very personal taste is against things like
| 
|      void foo(int /* i */) { }
| 
| which I don't believe is a fact.  OK, you offered the fact that
| the GNU standard library does not always use the form (1) above:
| this is a fact.

Well, you need to agree with yourself when a fact was given or not.
Saying no, then yes isn't helpful.

[...]

| (I wonder if,
| to be consistent, you should also advocate the removal of the unused
| argument warnings from g++.)

As a g++ user, probably yes.  *I* never saw its usefulness.  But I
understand that other peolpe do use it, and since I don't use it in my
own code its mere presence in the compiler doesn't bother me.

| I also do not consider a fact the suggestion that we should write
| a script to filter out warnings for each compiler we use, perhaps
| with variants for different compilation flags, perhaps changing
| the scripts to accommodate changes in GiNaC header.

First I never qualify that as a *fact* -- so I don't understand why
you're bringing it in the first place in this part of your reply.

Now, given the wide variety of kinds of noise^Wdiagnostics
different compilers output, I do consider that suggestion a good one.

[...]

| Perhaps the implicit suggestion we have been given is to stop
| compiling with extra warnings, but we don't want to do it.
| We did not invent the extra warnings options. 

Not just because you didn't invent them means you ought to use them.

[...]

| I keep my fingers crossed
| in the hope that the GCC developers will resist the temptation
| of screwing their header files in the name of abstract style
| considerations that do not take the user's needs into account.

Well, the header files were screwed (IMO) many times in the name of
"abstract style" considerations -- I can't say those modifications
were actually taking any input from users.  You can look in the
archives to see the logs.

We also use 

  #pragma GCC system_header

to make sure no warning will be output (with some set of options) just
because someone thought a given abstract style ought to be diagnosed.

Just learn to use the tool.

-- Gaby



More information about the GiNaC-devel mailing list