wmbiff: Manually copy mailbox path.
commit3b000774cc5156ce52b88c20d71aac1fe6a7aee3
authorDoug Torrance <dtorrance@piedmont.edu>
Sat, 24 Jun 2017 14:56:19 +0000 (24 10:56 -0400)
committerCarlos R. Mafra <crmafra@gmail.com>
Sat, 24 Jun 2017 16:07:02 +0000 (24 17:07 +0100)
tree99476ddcb49e2c1c6d3b67ca2983d3ff6f7361b9
parent24c0e4e4f2320faaf29198c6af2950f4a37b8d8e
wmbiff: Manually copy mailbox path.

Patch by Demi <m@tfiu.de> to fix Debian bug #621690.

From https://bugs.debian.org/621690:

> wmbiff change path of my mailboxes next nearest.
>
> For example wmbiff change 'gleb' to 'glil' for second and fourth mailboxes.
> However the 1st, 3rd and 5th mailboxes have correct path.

Well, the indices don't really enter.  I'm actually surprised this
isn't more trouble.

The underlying reason is that in wmbiff.c:parse_mbox_path, the
program calls

  mboxCreate((&mbox[item]), mbox[item].path);

which for maildirs calls

  int maildirCreate(Pop3 pc, const char *str)

in maildirClient.c.  str in this way is an alias for pc->path.

In maildirCreate, after some char acrobatics, the program eventually
does

  strncpy(pc->path, str + 8 + i, BUF_BIG - 1);

to cut off the leading stuff from the maildir.  The result of this
operation is not defined, as pc->path and str point to the same
memory and thus the arguments overlap, which strncpy outlaws.

A simple fix is to copy manually, like this:

DM(pc, DEBUG_ERROR, "maildir '%s' is too long.\n", str + 8 + i);
memset(pc->path, 0, BUF_BIG);
} else {
+ const char *sp = str + 8 + i;
+ char *dp = pc->path;
+
+ while (*sp && sp-str<BUF_BIG-1) {
+ *dp++ = *sp++;
+ }
+ *dp = 0;
- strncpy(pc->path, , BUF_BIG - 1); /* cut off ``maildir:'' */
}

-- it's what I'm doing now.  But I give you that's a bit pedestrian.
wmbiff/wmbiff/maildirClient.c