Re: [PATCH 01/14] Extend index to save more flags

[Jakub Narebski <jnareb@gmail.com>]

On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > > +
> > > +#define CE_EXTENDED_FLAGS (0)
> > > +
> > > +/*
> > > + * Safeguard to avoid saving wrong flags:
> > > + *  - CE_EXTENDED2 won't get saved until its semantic is known
> > > + *  - Bits in 0x0000FFFF have been saved in ce_flags already
> > > + *  - Bits in 0x003F0000 are currently in-memory flags
> > > + */
> > > +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
> > > +#error "CE_EXTENDED_FLAGS out of range"
> > > +#endif
> >
> >
> > I don't quite understand the above fragment (especially with the fact
> >  that CE_EXTENDED_FLAGS is defined as (0))...
> 
> Because this patch does not introduce any new on-disk flag yet so
> CE_EXTENDED_FLAGS remains 0. In the next patch, CE_EXTENDED_FLAGS will
> be updated to have CE_NO_CHECKOUT.

Well, now I understand CE_EXTENDED_FLAGS being (0).

What I still don't understand the pattern it is protected against.  
As I understand it if CE_EXTENDED_FLAGS & 0x0000FFFF it is bad,
because ce_flags saved flags are not extended flags, and 
CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags.  But why
CE_EXTENDED_FLAGS & 0x80C00000 is bad, and why (if I understand it)
CE_EXTENDED_FLAGS & 0x00300000 is not bad.

-- 
Jakub Narebski
Poland