[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] unseen sequence after inc into initially-empty folder
From: |
Ahmon Dancy |
Subject: |
Re: [Nmh-workers] unseen sequence after inc into initially-empty folder |
Date: |
Tue, 23 Sep 2003 13:36:57 -0700 |
>> > I do agree that mp->hghmsg++ is simpler than the whole chunk of code
>> > (which I copied from folder_addmsg). I do think that mp->lowmsg
>> > should be set to 1 if it was zero, though (since there is no message
>> > number 0). Here's why:
>>
>> Both calls to folder_realloc() in inc.c use 'mp->lowoff', not 'mp->lowmsg'
>> for the second argument 'int lo'. In 'folder_read()', this value will be
>> at least 1, so the particular code you mention won't fail.
Recall in my prior message that I said that it's the third check that
will fail:
if (mp->nummsg > 0 && lo > mp->lowmsg)
adios (NULL, "BUG: called folder_realloc with lo (%d) > mp->lowmsg
(%d)",
lo, mp->lowmsg);
If mp->lowmsg is not maintained properly (as it would be with the code
I suggested), it will remain 0. The check above will fail because, as
you said, lo will be at least 1:
if (mp->nummsg > 0 && lo > mp->lowmsg)
===> translates to
if (100ish > 0 && 1 > 0)
Let me mention, in case it wasn't clear, that I'm not speculating
here. I went throught this whole experience when I originally tried
to fix the unseen sequence on empty folders bug.
>>
>> In principle, I agree wholeheartedly about rigorous maintenance of state
>> variables. The whole business of dealing with the variables in
>> 'struct msgs' would be better handled with a C++ class, or just subroutines
>> that are called when members need to be changed.
Indeed.
>>
>> However, the nmh code set is a bit of jumble, and I really worry about
>> unintended side effects of a change that on the surface makes perfect sense.
>> So at this point I'd want to study the handling of 'mp->lowmsg' before
>> making the change.