Re: named warnings & individual warning control

[Phil Edwards <phil at codesourcery dot com>]

On Mon, Jun 21, 2004 at 03:08:49PM -0400, DJ Delorie wrote:
> 
> So, this is an attempt to summarize my opinion on the group consensus
> with respect to named warnings (and/or errors) and program control of
> such.

This is an attempt to provide feedback on your summary, w/o introducing
additional opinions.


> Some folks argue that the warning text should be in the source, others
> note the benefits of having a machine-parsable warning catalog
> (documentation, for example).  Both sides agree that gettext() is the
> i18n solution of choice.

I thought the Hivemind had finally decided on the catalog approach.
But possibly no consensus was reached.


> Warnings should be referenced by mnemonic, not number.  The mnemonic
> should match the command line option.

I believe that was the consensus.


> Warning control should be documented as something that WILL change
> from release to release of the compiler; users should expect such
> controls to be a "last chance" option, and any attempt to make the
> system easier for long-term use should be discouraged.  I.e.
> complaints that the #pragma to silence warning "foo" changed in this
> gcc release will be ignored.

I believe that was the consensus.  It should be emphasized, in the user
release notes, that "warning control" here refers to in-source control, not
(necessarily?) command-line options.


> It should be easy to audit warnings to ensure that they're properly
> emitted in accordance with the selected standard.

I believe that was the consensus.


> Changes in warning state should be both nestable and restorable.
> Simply "revert to initial state" is unacceptable.  In addition,
> historical state needs to be remembered such that it can be attached
> to a statement to see if a warning was enabled at that point in the
> program.

I believe that was the consensus, i.e., "Revert to initial" should not be
needed in properly-written code, and would be a major source of bugs in
users' projects.


> The internal API should allow for both "emit warning if needed" and
> "is this warning enabled?" functionality, in case the source needs
> custom logic to select warnings.

I believe that was the consensus.


> Whatever we do must support language and target specific extensions,
> both in format specifiers and message catalogs.

I believe that was the consensus.


> We should be able to specify, for each itemized message, whether it is
> ignored, emitted as a warning, or emitted as an error.

I believe that was the consensus.  There should also, if memory serves,
be a tie-in to the other levels of diagnostics.  Possibly also an in-source
control on the warning threshold.


> If supported, the pragma shall be "#pragma GCC warning ..."

I believe that was the consensus.


-- 
Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer.
                                          - Edsger Dijkstra, 1930-2002