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]
Other format: [Raw text]

Re: RFC: Named warnings


On 24-Jan-2003, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> 
> --On Thursday, January 23, 2003 05:06:16 PM -0800 Stan Shebs 
> <shebs@apple.com> wrote:
> 
> >As part of this individual control, each warning will get a unique
> >name, which consists of an alphanumeric string plus hyphens.
> 
> Overall, I think your proposal is fine, and I like the ideas about
> attributes.
> 
> I think the one sentence quoted above is a mistake.  I know people
> don't like numbers, but I think numbers are actually better here.

Why?

Below you say "They're shorter." and "They're language-independent.".
Are those your only reasons?

If so, I find them quite unconvincing.

> Some of the objections have been:
> 
> - The numbers will change.
> 
>  But, actually, they won't.  It's not hard to keep from changing
>  them, and I've worked on multiple compilers that had no trouble
>  keeping the numbers the same.

What did you do about warnings added on different development branches?

Was your experience with free software, developed by a wide variety of
different individuals and organizations, using multiple development
branches and with many organizations and individuals maintaining
patches or trees outside the main source code repository?

Using numbers poses far more problems if development is done by a large
number of separate organizations who do not merge there changes into
a single repository on a timely basis, as is the case with GCC, than
if development is done by a single organization with a single central
repository.

You can allocate chunks of the number space to different organizations,
different branches, etc., but then you need to use a sparse error number
space, which reduces the conciseness of the error codes, and also you
end up with very odd error message numbers that reflect the development
history rather than having anything to do with the nature of the warning.

> - The numbers aren't mnemonic.
> 
>  True, but how mnemonic are the literally hundreds of warnings in
>  the C++ front end going to be as foo-bar-baz strings?

Much, much, MUCH, *MUCH* more mnemonic than numbers would be.

Consider even the very worst names that Unix and C have given us,
such as mbstowcs(), strcspn() -- think how much more mnemonic
these are than numbers would be!  

Quick, what's the meaning of Linux signal number 30?

Well, maybe you remember that one off by heart, but I'll bet a lot of
readers don't.  On the other hand, mnemonics such as SIGPWR are a lot
easier to remember.

>  The way people actually use this feature in other compilers is like
>  this:
> 
>  (1) Run the compiler.
>  (2) Look at the warnings.
>  (3) Note that a particular warning isn't making sense for their
>      code.
>  (4) Insert a #pragma/attribute/comment to turn it off.

Right.  That's what they do when *writing* the code (or the Makefile,
etc.).  But that is *not* the only thing to optimize.  The other thing
to optimize -- and arguably it is more important -- is the ease of
*reading* the code.

>  Since steps 3/4 come together, something like:
> 
>    warning [123]: You're a moron, Mark.
> 
>  is easily dealt with; you copy the "123" into your code.

And then stop there?  Arrgh.

Good programmers copy the "123" into their code, and then *add a comment*
explaining what "123" stands for.

Unfortunately, however, good programmers are rare (and usually expensive).

Quick, what does a Linux errno value of 123 mean, as a return
value from the mount() system call?

You don't remember?  How about ENOMEDIUM?  Is that any easier?

> So, in favor of numbers:
> 
> - They're shorter.
> 
> - They're language-independent.

Language-independence is good, but not if it comes at the expense
of useful functionality and without any significant redeeming benefit.
IMHO the slightly shorter nature of numbers rather than mnemonic
error names is not nearly enough to justify the major loss of readability
for compiler options and pragmas.

>  GCC could have a manual section, like many other compilers, listing
>  all the warnings in numberical order with a description of what each
>  warning (and error) is about.

Sure, but the same could be done for non-numerical error codes just as
easily (in alphabetical order, of course).

Anyway, how is this going to help the poor Debian users who don't happen
to have a copy of the GCC manual handy?

> In any case, it would be a good idea to include errors in your scheme.
> 
> Also, some errors should have the ability to be turned into warnings
> (that's what -fpermissive does in C++, for example), and all warnings
> should have the ability to be turned into errors.  It makes sense
> to name/number *all* diagnostics, if for no other reason than
> easier documentation in the manual.

That would be OK with me, but if so, then IMHO there should be a
separate option which says whether or not to include message codes in
error messages, and furthermore IMHO that option should default to off.

If we do have such numbers, then it might be nice to have an option
which causes the compiler to output not just the name of the message,
but also a URL which would point to the relevant section of (the locally
installed copy of) the manual.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


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