On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote: > On 9/21/08, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
