Re: -Wall and all that

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On 17 Mar 2002, Kai Henningsen wrote:

> You obviously misunderstood the reference. I didn't mean using the  
> identifier to locate the message (I didn't even think of that), but if you  
> get a user report quoting error messages in chinese (say), those  
> identifiers would still enable you to understand what it's all about  
> without first asking for a translation.

You don't need to ask for a translation.  You can grep the .po files, or
rerun the compiler with the test file and options they provided (and
they'd better have made the text of the bug report itself be in English,
if they expect many people to read it - people not knowing English can of
course use e.g. localised GNU/Linux distributions, where the distributors
filter bug reports and send on translations).

> > > 4. Have pragmas to turn them on and off locally, say _Pragma("GCC warn yyy
> > > on") and _Pragma("GCC warn yyy off").
> >
> > This can be done gettext-style, by giving a regexp or substring to match
> > against the untranslated version of the message (which needs some changes
> > to make the untranslated version of the whole message be available at any
> > point, but is less invasive than solutions involving unique identifiers).
> 
> And the user then needs to know the untranslated version. This is *not*  
> user friendly.

There must be a check against the untranslated version, so that source
code is portable when compiled in different locales.  There might also be
a check against the translated version; that point wasn't much discussed.

We have enough trouble working out what warning messages should be under
what warning options.  If unique identifiers are to be assigned to
messages (rather than using the message text as its own identifier -
gettext vs catgets) we then have the problem of defining whether two
messages are "the same" (though in different code paths, or separated for
l10n convenience) or "different" - if "the same", users may want to
distinguish them, if "different", users may find that a nuisance when the
details of which of similar messages are given vary from compiler version
to compiler version.  Using the message text uses an identifier the users
are already familiar with (through seeing the same message appear in many
builds of the software, analysing it and concluding that the warning does
not represent a problem), and (with regexps) gives as much flexibility as
might be wanted to choose how much the message can vary and still be
ignored.

There are many places in the testsuites where the regexps for messages are
deliberately vague, to allow for variation in messages.  If making a
compiler change that alters a message, and both the old and new messages
were correct, it makes sense to make the regexp allow both old and new
versions - as well as allowing for future change, this makes the
comparison of the new testsuite running with old and new compilers more
meaningful.

-- 
Joseph S. Myers
jsm28@cam.ac.uk