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


>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

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

    Jeffrey> You explicitly select the warnings you decide are
    Jeffrey> appropriate and make your code avoid such warnings.

    Jeffrey> Anybody that uses -Wall blindly is bound to run into
    Jeffrey> problems simply because the warnings that the egcs
    Jeffrey> project decides are useful for -Wall are not necessarily
    Jeffrey> those which everyone will consider useful for -Wall.

Right!  But, at present, there's no way to select which warnings you
want at the level of granularity that many people might desire.  And,
I don't think we want to add tons more -W<xxx> options, and all the
accompanying `if' statements to manage them.  In any case,
command-line options don't give you a way to say what warnings you
want for particular pieces of code.

    Jeffrey> First, we don't want #s.  Really we don't.  I've worked
    Jeffrey> with such systems, it sucks.

Do you mean as a user, or as a developer of the system?  I agree that
numbers aren't ideal, and I'm happy to take suggestions for better
mechanisms.  But, I too have worked with such systems, in both
capacities and I've found that:
  
  o As a user, if the compiler tells me the error # when it issues
    the error (my patch had an option to enable this behavior), 
    it's easy enough to figure out which numbers to use.

  o As a devloper, if the warnings are together, in a single file,
    it's easy enough not to perturb things: only add to the end of the
    file, and never remove entries.  (You can stop referencing the 
    warning, you just can't pull it out of the file.)

Furthermore, using mnemonic names for the warnings would just add to
the internationalization problem we already have: "-Wno-sign-compare"
may be intuitive to you but probably isn't to some who doesn't speak
English.  Unfortunately, it doesn't make sense to translate
command-line options, or the arguments to #pragma's, __attribute__,
and so forth because we want the same source code to compile no matter
what language the person compiling it happens to speak.

    Jeffrey> Agreed.  Both numbers and small criptic keywords are bad
    Jeffrey> for this kind of stuff.  The message belongs in the
    Jeffrey> source.  This is also compatible with how GNU gettext
    Jeffrey> works, which we will be using as part of the effort to
    Jeffrey> improve internationalization support in egcs.

As I've mentioned before, my patch has absolutely no affect on the use
of gettext, except, IMO, to make it even easier to use, since the `_'s
don't have to go in all the source files, but only in one place.  In
fact, you don't even have to worry about forgetting the `_' when you
add a new message!  I realize now that I used bad wording in my
original message; I lead some people to believe that I was proposing
some alternate means of internationalization.  I was not.

Yes, the error messages are removed from the source code itself.  In
my patch, they were replaced by enumerals like `you_did_x' for a
message like "you did x", which I don't think is so unreadable.  For
that, we get a lot of leverage; like the ability to disable related
messages. 

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