This is the mail archive of the gcc@gcc.gnu.org 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]

Re: Warnings in the C++ Front-End and GCC in General


On Mon, 7 Sep 1998, Richard Henderson wrote:

> > This patch addresses a long-standing need in GCC: the ability to
> > disable individual warnings.
> I don't necesarily agree that it is a need at all, but...

IMHO, it is needed now, and is even more likely to be needed in future.
GCC provides more and more diagnostics and it becomes increasingly
difficult to write code that compiles cleanly in reasonably strict
compilation mode.

What if you worked for a company that required, as part of their coding
style, warningless compilation?

Personally, I hate it when I have to provide bogus initialisation for auto
variables or provide unreachable return statements just because the
compiler is not smart enough. I understand that it's unreasonable to
expect it to be so smart, but still I hate being forced to cheat it.

I strongly prefer putting some obscure pragmas in the source code to
cheating the compiler or disabling warnings (which, as pointed out above,
is not always possible).


I understand your concerns. This feature, if overused, will turn into a
portability and maintenance nightmare. However, portability is not always
important even in free software community.

> By number is particularly odious.  One, now we've got to manage
> numbers.  Two, we've got to preserve numbers from revision to
> revision -- they've just been enshrined as part of the GNU C API. 
> 
> In all, it sounds like a maintenance nightmare.

I fail to see your point. What is so difficult in managing numbers or
preserving them from revision to revision? Sure, it requires more careful
thinking before adding or changing warnings, but this is an advantage.
Currently, some warnings are added "just like that", because the author
thought they are "cute", or that "nobody in their right sense would write
something like this". It is only when other people try to compile their
projects, often some legacy code, that they notice what a poor idea the
warning was.

> This could be partially mitigated by using small, cryptic keywords
> instead, but I'm not sure how much that buys us either.

Small, cryptic keywords are not an advantage to numbers, IMHO. With so
many warnings as in GCC, the keywords won't be small, that's for sure. I
strongly prefer numbers, they at least look neat. Sure, numbers are
obscure, but that can be turned into advantage: user's won't overuse the
feature if it's difficult to use.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets GCC maintainer   UNIX system administrator       |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /



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