On 2018-07-23 20:47:34 -0700, Kevin J. McCarthy wrote:
> On Tue, Jul 24, 2018 at 04:47:43AM +0200, Vincent Lefevre wrote:
> > On 2018-07-22 09:54:44 -0700, Kevin J. McCarthy wrote:
> > > I think the second time is okay. The routine is just resorting, and
> > > updating the virtual and v2r fields w
On Tue, Jul 24, 2018 at 04:47:43AM +0200, Vincent Lefevre wrote:
> On 2018-07-22 09:54:44 -0700, Kevin J. McCarthy wrote:
> > I think the second time is okay. The routine is just resorting, and
> > updating the virtual and v2r fields with the assumption that the actual
> > visible headers hasn't c
On 2018-07-22 09:54:44 -0700, Kevin J. McCarthy wrote:
> On Sun, Jul 22, 2018 at 03:35:38AM +0200, Vincent Lefevre wrote:
> > I'm wondering whether there could be similar bugs in other parts
> > of the code, where vcount is reset to 0, but not vsize.
>
> Nice sleuthing!
>
> > mbox.c has:
> > [...
On Sun, Jul 22, 2018 at 03:35:38AM +0200, Vincent Lefevre wrote:
> I'm wondering whether there could be similar bugs in other parts
> of the code, where vcount is reset to 0, but not vsize.
Nice sleuthing!
> mbox.c has:
> [...]
> but nothing related to vsize.
Since this is a reset (reopen), I th
While testing the new code related to limited view, I noticed
an old standing bug: ctx->vsize wasn't reset in this code.
I'm wondering whether there could be similar bugs in other parts
of the code, where vcount is reset to 0, but not vsize.
mbox.c has:
ctx->hdrmax = 0; /* force allocatio
