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

[Craig Burley <burley at gnu dot org>]

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

"A reasonably strict compilation mode" will either allow omitting
warning *classes* like -W or -Wall, or will *disallow* use of
pragmas and the like to disable specific warnings, IMO.

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

I'd do what I've done with g77 for years -- get it to compile as
cleanly as possible with -W -Wall, then, if I can't get rid of a
few annoying warnings due to compiler bugs/misfeatures, turn off
-W and/or -Wall for the company's "benefit".

I sure wouldn't decorate my Makefiles or *especially* my source
with what amounts to *internal* compiler information.

If the company I worked for demanded warningless compilation even
with -W -Wall yet *allowed* use of this new facility to "get around"
the problem, I'd either quit, or, more likely, have the bozo who
made up *those* rules fired.

>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 agree, this is a bit annoying, but disabling specific warnings
by arbitrary number or keyword is, IMO, a cure worse than disease.

>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'd like to know how in the world you could possibly *strongly* prefer

  #pragma warning_off 62
  int foo;
  #pragma warning_on 62

to:

  int foo = 0;

Which brings me to another question I didn't ask earlier: is this
facility designed to copy the entire warning-enabling "state" around
with declarations, definitions, and so on, so subsequent phases in
the compiler will have the information handy when they need it --
which, in most cases I suspect, will *not* be right after the
relevant source text has been parsed?

That is, is my above guess at how the pragma facility would work
going to "certainly" disable a warning (numbered 62) about `foo'
being uninitialized, or will the warning_off pragma have to
*precede* the beginning of the function definition and/or will
the warning_on pragma have to *follow* it?

In other words, has the granularity of this facility been properly
designed and implemented?  I didn't review the patch carefully to
see.

Note that, even if we get it as "right" as possible, people will
email plenty o' bug reports about how it doesn't quite work the
way they expected.  But getting it "righter" will lower the number
of bug reports we get regarding this facility.

OTOH, getting this "really wrong" doesn't make the facility a
non-starter IMO at all -- it just makes it easier to convince
people to not use it unless they really, really, really have to,
which is not a bad thing.  (And the fact that I, and probably
others as well, are claiming this facility is better offered as
an underpowered one suggests to me it is, conceptually at least,
a non-starter.)

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

In which case people can write scripts using sed/grep or whatever
works for them, and we can leave mucking with the compiler internals
out of the picture entirely.

So, if somebody's pointer-haired boss wants no warnings, but might
do some "midnight test" to see if *some* warning gets produced, the
brilliant programmer can have the Makefiles substitute "mycc" for
"gcc" more easily than providing a bunch of options like -Wdisable-62,
and have his `mycc' script run `gcc' and omit the warnings he knows
are "okay" in specific areas of the code.  (The diagnostics contain
the line numbers, after all, at least in most cases.)

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

Then the solution is to get rid of, or fix, the warning.  Once
this proposed mechanism becomes accepted, however, another solution
will be much more tempting: "leave it in, let individual users
disable it specifically if they want".

Trust me: if we indeed can't keep ourselves from adding "cute" warnings
to egcs, we'll *completely* mismanage this new system for labeling
warnings.  Better a few bad "cute" warnings than a completely new,
and mismanaged, facility that'll find its way into all sorts of
end-user C and C++ code.

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

Well, they'll constantly ask us to make it easier to use, at least.

And, look up emails to egcs about "regparm" to see what kind of stuff
we have to put up with once even a *useful* feature (performance-wise)
is made available to the community as a language "feature".

My nightmare about this proposed facility is that, within about two
years, we'll be getting email from Linus Torvalds accusing one or
more of us of being gutless coders because we don't dive in and fix
some less-than-precise warning to at least work the way it used to,
because Linux, by then, will be using this feature in combination
with other clever hacks to compile even faster versions of Linux.

(And, yes, I can imagine all sorts of wonderfully clever hacks that
I, at least, could come up with to exploit this facility in
combination with more and more generally-useless warnings.)

I think my biggest concern is simply this:

  None of the egcs "languages" are properly described as "very
  powerful macro processors that produce assembly code".  If people
  want such a thing, they can design and build that themselves, but
  C and C++, for examples, are bad languages pretty much to the extent
  they were designed to be such a thing, and good languages to the
  extent they weren't.

  Instead, egcs supports "languages", albeit artificial ones, in the
  wider sense than is meant by "formal language" in computer science.
  This wider sense includes offering programmers ways to express
  themselves by saying what they mean (my "SWYM" principle), ideally
  in ways that are difficult for any reader to misunderstand.

  As such, we should not be adding to them facilities that amount to
  exposing the internals of any particular compiler.  Such facilities
  inherently violate the SWYM principle, because a programmer *never*
  means to fiddle with compiler internals in his own user code --
  if he did, he'd just fiddle the compiler internals, or write
  assembler code directly.

  If we implement the new facility as proposed, we can either ignore
  this advice and make life easier for ourselves in the short term
  (and learn to say "no" to an increasingly large barrage of "bug
  reports" about "incompatible" warning behavior, etc.), or we can
  try and "take" this advice and thus be responsible for adding an
  entirely new facility to the C and C++ language dialects, one that
  adds not one bit of expressiveness to the languages, and which
  will require substantial resources to maintain.

In my estimation, this would parallel somewhat the __asm__ facility
in gcc, though with much less overall utility.  As maintainer of g77,
I am highly grateful I haven't tried to offer the equivalent facility,
even though I *know* it'd be useful -- because, while intended for
"macho programmers" who know what they're doing, inevitably too many
programmers *think* they do when they don't, then complain when the
compiler doesn't diagnose their bad assembly code.  I think I'd find
that less amusing than I do if it came from Fortran programmers using
g77, because in that case I'd probably feel motivated to do something
about the "problems" being reported.  :)

(Lest anyone think I oppose the notion of very powerful macro processors
that produce assembly language -- please don't.  I've been designing
the "ultimate system" for that sort of thing in my head for about
20 years now.  It's just that I understand the differences between
that sort of system and what egcs provides, and see this proposed
mechanism as a case of trying to make the latter into the former,
a transformation that will never truly happen, resulting in an
increasingly byzantine mess that looks vastly more useful than it
actually is.)

        tq vm, (burley)