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

[Mark Mitchell <mark at markmitchell dot com>]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

    >> I don't understand this comment.  Sometimes, one must use
    >> source for which one does not have write access.

    Per> I meant using sed (or something similar) on the stream of
    Per> output messages.

    >> Foundry is not free software, IIRC.  Not everyone uses emacs.

    Per> Foundry and Emacs compile mode were meant as two examples of
    Per> Gcc front-ends where one could reasonably add an error
    Per> message filter.

Thanks for clarifying!  I now understand what you meant; my previous
reply made no sense in that light.  Yes, various front-end filters are
useful.  However, it's sometimes necessary to prepare source (such as
library header files) which will be used by people with a variety of
front-ends.  It also makes sense to mark, *in the source*, the places
where you're doing something odd, rather than writing a filter.  For
example, if you only want to disable a warning for the next few lines,
it's hard to write a filter that can handle this, and will not get
confused by subsequent changes to the source.

Also, such filters are not robust in the face of changes in the
(natural) language used for the output; writing a filter that works
both for English and for Italian error messages might be tricky.  Most
importantly, such filters are not robust in the face of changing the
precise wording of the messages themselves, or in their various
translations. 

    >> For example, g++ sometimes issues multi-line messages where the
    >> first line uses one message, and subsequent lines use another.

    Per> This is a bug.  We really need to have a convention for
    Per> multi-line error messages so that we (and emacs compile mode)
    Per> can reliably and unambiguously distinguish between the first
    Per> line of a message and subsequent messages.

I agree with this.  But, it was a specific case of a more general
issue.  For example, g++ sometimes issues slightly different messages
when discussing types vs. functions or pointers vs. references, or
what have you.  In these cases, you'd like to get rid of the class of
warning as a whole, rather than by the individual message text.

    >> In summary, it's my opinion that the functionality I proposed
    >> is not available as a simple gettext extension.

    Per> I can go along with that, but it seems like the two features
    Per> (controlling suppressing of messages, replacing some messages
    Per> by a translation) are rather similar, and should both be
    Per> handled using the same general framework, rather than two
    Per> separate frameworks.

Framework, is, I think, too large a term for what I proposed. :-) But,
I don't really see the reason these two should be combined.  The job
of libintl is internationalization; given a string in some natural
language (often English) provide the equivalent string in some other
language.  Sometimes, libintl is used for error messages; sometimes
for other purposes.

The notion of error messages as used in GCC is peculiar to (unnatural)
language processing tools, and has a different set of constraints and
uses.  I think using libintl in GCC makes a lot of sense; that gets us
internationalization.  Providing a way to control *which* messages
come out is probably not within the scope of libintl, in my opinion.

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