This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Named warnings
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
- Cc: Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard dot Earnshaw at arm dot com
- Date: Fri, 24 Jan 2003 18:01:27 +0000
- Subject: Re: RFC: Named warnings
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Mark Mitchell <mark@codesourcery.com> writes:
>
> > --On Friday, January 24, 2003 11:33:49 AM +0000 "Joseph S. Myers"
> > <jsm28@cam.ac.uk> wrote:
> >
> > > On Fri, 24 Jan 2003, Mark Mitchell wrote:
> > >
> > >> So, in favor of numbers:
> > >>
> > >> - They're shorter.
> > >
> > > Either they're longer (md5sums of the message, or from /dev/random) or
> > > else you likely get clashes when two patches adding new warnings are
> >
> > It's really not very hard. You add to the end of an enum. Every
> > now and then there's a conflict, and someone has to go first; that's
> > an easier merge than most and it will happen rarely.
>
> I'm not really sure this will work so well. There might be gcc
> branches with new warnings that are kicked along parallel to the
> "main" gcc for years, and in that time, people either couldn't use the
> warning numbers, or they'd have to change them at merge time.
That's easily solved. Just declare the master file to be the mainline. A
warning number is never added on a branch without first adding it to the
mainline (note: it's only the number that's added on the trunk). If the
branch dies without being merged, then the number can be recycled, but I
doubt even that is really necessary.
R.