gordon@sneaky.UUCP (10/29/84)
There is a bug in the DBM code in news 2.10.2 inews. When findhist() in funcs2.c looks up an article id, it gets the file offset in the history file back as the data. This information is used incorrectly. It uses the core address of the data as a file offset, instead of what the pointer points to. The effect is that the wrong file offset is used, and if the article happens to be at the beginning of the history file (on my system this means the first 40k of it), it won't be found. (If the core address happens to be smaller than the correct file offset by at least 1 line length, the entry will be found anyway, slowly.) Article cancellations fail, and some articles may be needlessly re-transmitted. "rhs.dptr" is a char pointer, and what you want to do is pick up the long it points to. On some machines *( (long *) rhs.dptr) would work, but there is no guarantee that rhs.dptr points to something on correct alignment for the machine involved. Therefore I present the following ugly-looking but reasonably portable change: 305a306 > long fpos; 330c331,333 < fseek(hfp, (long)rhs.dptr, 0); --- > for (p = (char *)&fpos; p < (char *)(&fpos + 1); p++,rhs.dptr++) > *p = *(rhs.dptr); > fseek(hfp, fpos, 0); There is another problem I have not figured out yet. If you cancel an article with an id that hasn't been seen yet, inews calls savehist() to mark the article cancelled in the history file, and it dumps core somewhere in the middle of the dbm store() call. The dbm buffers _pagbuf, _dirbuf, and most of bss area past that seems to be trashed. To repeat: /usr/lib/news/inews -n control -t "cmsg cancel <1@sneaky.BUGS>" I sure hope there is no net "BUGS" out there. ^D The inews process spun off into the background dumps core. You probably have to be running as news to get a core dump, since inews is setuid, and many systems don't dump core if real and effective uid's are different. Gordon Burditt convex!ctvax!trsvax!sneaky!gordon microsoft!trsvax!sneaky!gordon