On Thu, 07 Oct 2004 14:19:26 +0200, Paul J Stevens <[EMAIL PROTECTED]> wrote:
> I've tracked down the problem in the old mimeparser. Straight headache stuff.
> A
> typical off-by-one error.
That code sure is a real nightmare.. (I'm glad you're getting rid of
it in your new code).
>
> In fact this is so arcane I don't really understand it. Maybe Ilja or Roel can
> shed some light on this. The patch that fixes the problem:
I don't have a clue... Roel has just recently quit working here (he
wants to finish his physics studies) so I can't ask him. But I guess
he wouldn't know the answer as well.
>
> diff -u -r1.17 dbmsgbuf.c
> --- dbmsgbuf.c 2004/09/15 13:08:27 1.17
> +++ dbmsgbuf.c 2004/10/07 12:13:30
> @@ -218,7 +218,7 @@
> /* move buf to make msgbuf_idx 0 */
> memmove(msgbuf_buf, &msgbuf_buf[msgbuf_idx],
> (msgbuf_buflen - msgbuf_idx));
> - if (msgbuf_idx > ((msgbuf_buflen + 1) - rowpos)) {
> + if (msgbuf_idx > (msgbuf_buflen - rowpos)) {
> zeropos.block++;
> zeropos.pos = (msgbuf_idx - ((msgbuf_buflen) - rowpos));
> } else {
>
> I'm guessing the +1 was added to compensate for bugs elsewhere sometime ago.
This could well be..
>
> Some logentries that look possibly related:
>
> revision 1.8
> date: 2004/04/14 09:04:55; author: ilja; state: Exp; lines: +2 -1
> msgbuf_buf is now initialized to hold '\0' on start.
>
> revision 1.5
> date: 2004/03/16 15:54:59; author: ilja; state: Exp; lines: +9 -2
> No longer adds the '\r' on the end of every line. Now only adds it if
> the line is ended with a single '\n' and not with '\r\n'
>
I've checked the diffs on those entries. They don't really seem related to me.
Ilja
