Thanks all. it's interesting that announce.c doesn't have the same problem:
cpue% grep -n NETPATHLEN /sys/src/libc/*/*.[ch] /sys/src/libc/9sys/announce.c:73: strncpy(dir, buf, NETPATHLEN); /sys/src/libc/9sys/announce.c:74: dir[NETPATHLEN-1] = 0; /sys/src/libc/9sys/announce.c:124: strncpy(newdir, buf, NETPATHLEN); /sys/src/libc/9sys/announce.c:125: newdir[NETPATHLEN-1] = 0; /sys/src/libc/9sys/dial.c:48: char dir[NETPATHLEN+1]; /sys/src/libc/9sys/dial.c:229: strncpy(ds->dir, conn->dir, NETPATHLEN); /sys/src/libc/9sys/dcpuial.c:230: ds->dir[NETPATHLEN] = '\0'; /sys/src/libc/9sys/dial.c:459: snprint(conn->dir, NETPATHLEN, "%s/%s", cname, name); On Sat, Sep 8, 2012 at 9:26 PM, erik quanstrom <quans...@quanstro.net> wrote: > On Sat Sep 8 23:02:25 EDT 2012, charles.fors...@gmail.com wrote: > >> No, I didn't explain it well. NETPATHLEN isn't named in the manual >> pages, so ndb/dns doesn't use it. On the other hand, dial does, but >> because it's ...LEN, it's an easy mistake to think of it as the length >> of a string, which wouldn't include the terminating zero byte, instead >> of the length of the underlying array. > > indeed, a fair number of recent dns issues have been this sort of confusion. > there is something in ndb/dns (at least for me) that induces confusion. > > - erik >
