>> > On Sun, 2009-02-15 at 02:05 +0900, Masatake YAMATO wrote:
>> > > Hi,
>> > >
>> > > Could you merge this patch if it is correct?
>> > >
>> >
>> > The optimizer benefits from the else on some archs/compilers and it
>> > doesn't cause any harm so I am inclined to leave it the way it is.
>>
>> I think the 'else' causes harm.
>>
>> Look at the local variable `start'.
>>
>> `start' is initialized to 0.
>> Then `start' is set to 1 in "if (throw_away_mode == THROW_AWAY_ACTIVE) {}"
>> block.
>>
>> The value of `start' is refereed in "if (throw_away_mode ==
>> THROW_AWAY_INACTIVE) {}" block.
>>
>> If the "else" is there, start is always 0 in
>> "if (throw_away_mode == THROW_AWAY_INACTIVE) {}".
>> I could not understand why `start' is set to 1 in
>> "if (throw_away_mode == THROW_AWAY_ACTIVE) {}"
>>
>> Masatake YAMATO
>>
>
> The start is an artifact of bad code which has no effect because the
> else is present. If we were to remove else, we should also remove start
> entirely. Removing start entirely isn't a bad idea at all since it
> needlessly complicates the code with no benefit.
>
> The way it is supposed to work is if throw away mode is active, no
> messages are delivered. If throw away mode is inactive, all messages
> are delivered.
>
> The reason start is in there is to throw away the first fragment of a
> transition from active to inactive. I don't think this is necessary and
> would produce incorrect results. (but this is kind of how the code
> worked before).
I see. Thank you for explanation.
Masatake YAMATO
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais