On Mon, 22 Sep 2008, Duy Nguyen wrote:
> On 09/22/2008 "Jakub Narebski" <jnareb@xxxxxxxxx> wrote:
>>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.
>
> 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
--
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
