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

[Craig Burley]

>    I, for one, will oppose and C++ warning that
>    I don't think is going to be useful a lot more often than not.

That's great, but there's perhaps a bit of irony here: I don't
think this proposed *mechanism*, as a whole, will be useful more
often than not, certainly not by a lot.

But, it might go in anyway, over *my* objections (such as they are).

The irony is that, someday, *you* might object to a new warning
on the grounds you now state.

And, the response is likely to be: "but, with this great facility
to enable/disable specific warnings, the validity of any particular
warning is no longer of import".

In other words: by offering this new facility, you render you
own basis for objecting to new warnings vastly less relevant!

>    I used to work on an error-checking C/C++ system (at CenterLine,
>    these were the Saber-C/C++ -> CodeCenter/ObjectCenter -> C++Expert) 
>    series, and believe me, we learned the value of avoiding false
>    positives!  We also learned how important it ws for users to be
>    able to suppress warnings and errors effectively.

I absolutely agree it is important.  I believe this mechanism is,
in almost all cases, a cure worse than the disease.

>  o You also point out that:
>
>    > No new, readable, linguistic information is added to the dialect
>    > The facility is inherently non-portable
>
>    Both true.  Unfortunately, I don't really see a way around these
>    issues.  We don't issue the same warnings as other compilers,
>    so portability doesn't seem likely.  And, warnings, as opposed to
>    errors, usually indicate that some construct, while legal, is
>    unlikely to be the one you wanted.  So, I'm not sure what 
>    linguistic information would be useful.  Instead of numbers
>    we could use mnemonic codes, perhaps the error codes themselves?
>    Would you rather use:
>
>      __disable_warn__(blah_blah_you_really_maybe_meant_blah)
>
>    as opposed to:
>
>      __disable_warn__(85)
>
>    I rejected these as being too hard to type, and because it would
>    mean that non-English speakers would have to use English codes 
>    for error messages.

No, I'm thinking about things from a completely different tack.

For example, instead of changing

  int foo;

to

  int foo = 0;

to avoid an uninitialized-variable warning, wouldn't it be nice
to be able to say something like

  int foo = __undefined__;

to mean, literally, "foo is *known* to be not defined initially,
and that's okay", and which differs from "int foo;" *only* in the
sense that the programmer is saying "I know it is okay to leave
foo undefined".

(Not that I'm proposing this particular extension, especially in
that form, but perhaps in *some* form it'd be useful, and IMO in
almost *any* form it'd be more useful than the corresponding
pragma mambo.)

Carefully considering how to offer elegant, linguistically consistent
means to express that a warning is inappropriate in a given instance
is much harder, especially since it needs to be done in a distinct
fashion for C, C++, Fortran, Pascal, Ada, and so on, compared to
simply offering the pragma facility you propose.

But, it's also much better, and once your facility goes in, the
better approach will become much less likely to be seriously
undertaken, because too many people will see the problem as "solved".

>    I think that over time the "warning contour" *is* likely to
>    change, at least slightly.  People who use the warning diable
>    facilities heavily in their code, especially to cover up real
>    problems, will suffer as a result.  Appropriate cautionary notes
>    in the manual are probably in order.

And will not be read.  :)

>  o You suggest that:
> 
>    > some of this is just working around significant
>    > deficiencies in C, C++, Fortran, et al as programming languages
>    > (which we could try and solve
>    
>    There are certainly deficiencies in all those languages.  They
>    are, however, the languages mandated by their appropriate
>    standards, and there's not much we can do about them.  I think GCC
>    has too many odd extensions as it is.  But, perhaps that's not
>    what you meant?

You've hit on it somewhat.  But adding pragmas amounts to "doing
something" about the languages as standardized anyway.  That is,
adding extensions to the languages is really no different from
adding pragma meanings, in any real sense -- especially since there
are *no* such things as pragmas in Fortran, for example.

>  o Although you point out that figuring out where a particular error
>    is coming from gets a little harder, I'll point out that a simple
>    emacs macro (or shell script) should fix that problem.

I agree.  I think it's conceptually cleaner to have a central data
base of diagnostics, combined with readable mnemonics in the code
to make the linkage, with, where feasible, a nifty editing environment
that can "pop up" the expansion where suitable.

>    o A single mechanism for generating diagnostics will allow 
>      more code sharing/reuse.
>
>    o Internationalization should be easier if messages are collected
>      in a single file, not in the bowels of the source.
>
>    o It will be easier for people who find mis-worded or unclear 
>      messages to submit patches to fix them, and easier for us
>      to accept them.

100% agree to all that.

        tq vm, (burley)