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

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 22 Sep 2008, Duy Nguyen wrote:
> On 09/22/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>>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.
> 
> Wrong bit computation, should be "#if CE_EXTENDED_FLAGS & 0x803FFFFF".
> Thanks for pointing out. 

So now there is:

Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
  * CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
  * CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
  * CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
    (this is not mentioned in quoted comment; I'm not sure if
     it needs to be or not)

Is that correct?
-- 
Jakub Narebski
Poland