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


>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

    Craig> A *big* disadvantage of numbers is that it becomes much
    Craig> harder to reliably search for all instances of where a
    Craig> particular diagnostic is issued in the code.  With
    Craig> mnemonics -- regardless of the language they're written in
    Craig> -- the reliability goes up much higher, especially if the
    Craig> creators of the mnemonics understand the importance of this
    Craig> capability.  (Try searching for 62 in gcc, as compared to
    Craig> searching for "uninitialized var", or some such thing.  In
    Craig> g77, the distinction is likely to be even more useful.)

I think this is discussion is largely moot as Jeff has exercised his
veto authority on my proposal.  But he can't keep us from talking
about it, now can he? :-) :-)

    Craig> It might be instructive for some people to look at g77's
    Craig> handling of the issues.  It has *two* mnemonics for some
    Craig> diagnostics, and at least one for most of them:

    Craig> None of the above are true for the rest of egcs (well, gcc
    Craig> anyway) currently.  Mark's patches accomplished most of the
    Craig> above, I assume, though using numbers rather than names and
    Craig> not offering the doc aspects (at first, anyway -- these
    Craig> could "fall out" of his work fairly naturally, I would
    Craig> think).

If I'd been familiar with your scheme I would have adopted it.  It
sounds like it accomplishes most of the things I had set out to do,
from an infrastrure point of view.  Adding the capability to disable
particular warnings would be easy with your system; you just don't
want to do it.  Even without that capability, I would prefer your
system to what we currently have now; while some find the use of
strings scattered throughout the source convenient, I find it somewhat
disorganized.  Diagnostics are more than strings: they have much more
semantic content.  There are various ways in which we could use that
content if it were avaiable to us.

It sounds like I re-invented most of your wheel, minus the doc-hook
bit, although, as you point out, that would have fallen out easily.
One thing you may have misuderstood about my scheme was it's use of
numbers.  Like your scheme, errors were represented by mnemonics in
the code.  For example, the error "uninitialized variable" became the
enumeration constant ec_uninitialized_variable.  The numbers
themselves appeared *nowhere* in the source.

The only use of numbers was in the command-line options users could
use to disable the warnings (and in the proposed #pragmas, for similar
effect).  We could just as easily have used the enumeral names there,
or, as you suggested, alternative names more fit for public
consumption, if that's what people prefer.  I simply followed
convention found in other compilers I've worked with and on.  But, I
don't think it was just the use of numbers that resulted in the death
of my proposal.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


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