jay@splut.UUCP (Jay Maynard) (03/04/88)
I have the 1/88 release of Bob McQueer's vn news reader, and have run into a
problem: If I specify '-n talk.all' on the command line, I get a
segmentation violation in specmark() trying to convert the .all into .*. The
actual dump (according to sdb) is in a routine called by regcmp().
Has anyone else run into this one? Is it a bug in Microport's library or in
vn?
--
Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603
uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
The opinions herein are shared by none of my cats, much less anyone else.mike@cimcor.UUCP (Michael Grenier) (03/06/88)
From article <402@splut.UUCP>, by jay@splut.UUCP (Jay Maynard): > I have the 1/88 release of Bob McQueer's vn news reader, and have run into a > problem: If I specify '-n talk.all' on the command line, I get a > segmentation violation in specmark() trying to convert the .all into .*. The > actual dump (according to sdb) is in a routine called by regcmp(). > > Has anyone else run into this one? Is it a bug in Microport's library or in > vn? > Yes, it is a bug in the regcmp library. A corrected version is available from the Microport BBS (1-408-438-6567 or 6687) @2400 baud if you have paid for the hotline or update service. 'pose they'd get up set if I mailed it to you... vn works fine now on my uport 286 system. -Mike {rutgers, amdahl, ihnp4}!bungia!cimcor!mike
bobm@rtech.UUCP (Bob McQueer) (03/09/88)
From article <402@splut.UUCP>, by jay@splut.UUCP (Jay Maynard): > I have the 1/88 release of Bob McQueer's vn news reader, and have run into a > problem: If I specify '-n talk.all' on the command line, I get a > segmentation violation in specmark() trying to convert the .all into .*. The > actual dump (according to sdb) is in a routine called by regcmp(). > > Has anyone else run into this one? Is it a bug in Microport's library or in > vn? > I don't know anything about microport. Just a few words copncerning use of regcmp in vn: The intent is that on SYS V systems you do not use the source file reg.c. That source file implements regcmp / regex on top of the berkeley routines re_exec() and re_comp(). This statement also extends to non-SYSV systems which happen to have regcmp() regex() in their libraries. If using a system defined regcmp() / regex(), it is imperative that you include -dregfree=free in your cc options. The way I'm running vn here includes the following systems: Ultrix on microvax: using system regcmp() / regex() CCI / Pyramid / Sun: using reg.c implementation. At one point I linked using the SYSV libraries on Pyramid also, but I've been too lazy to swap to the att universe over there to link it :-) (it also means I can use the same makefile to link the Sun version - the Pyramid happens to be our NFS file server) All of the above work fine. I've received word from people running on non-microport sysV systems that they work OK, too. If you're using the system regcmp() I'm inclined to say that something is funny about your regcmp(). If you're linking in reg.c, that was not the intent. Somebody about a week back posted a bunch of patches to reg.c with #ifdef SYSV's in them. If that makes things work for your system, fine. I believe they were posted to comp.sources.d. It has been brought to my attention that -lPW options are now needed on many SYSV systems to pick up regcmp(). I will go ahead and put that in the default Makefile. There is a small bug concerning the conversion of "all"'s in option strings, but which has nothing to do with this discussion - strings with multiple "all"'s in them do not get handled properly - "all.all" becomes "..*ll" instead of the intended ".*.*". I will say something about that in a different article - basically things with multiple "all"'s in them wind up matching nothing. I don't want to pull those patches into mainline vn on the grounds that I believe the regcmp() / regex() use is correct, and reg.c is intended ONLY for BSD systems. If there is something illegal about the regcmp() / regex() calls, it's better to fix it by using them legally. In a nutshell, the assumed interface within vn is: char *regcmp(re_str, (char *) 0) char *re_str; returns a character pointer to the compiled form of the re, which is to be used as an argument to regex(). It is perfectly legal to have several regular expressions compiled simultaneously (the feature missing from BSD re_exec and re_comp - the reg.c code keeps track of the "current" string and recompiles it as neccesary). The memory for the compiled string is dynamically allocated, and may be used as an argument to free() once you're done with it. This routine may actually support several string arguments, hence the (char *) 0 terminator, but vn only ever uses 1 argument. char *regex(re,str) char *re; char *str; returns non-NULL if str matches re, the pointer returned by a regcmp() call. Actually returns a pointer to the end of the match, but vn never actually cares about that. This routine can also be passed an arbitrary number of arguments for return of (..)$n type subexpressions. Using such things will break vn because there is no argument passed in for the return of the subexpression. Because this is a very obscure piece of RE syntax that nobody is likely to enter by accident, and it requires an arbitrary length argument list on the regex() call (nothing to prevent somebody from returning a subexpression in the 120th argument, say), I don't propose trying to fix it. I suppose it could also be fixed by scanning for the offending thing and removing it before calling regcmp, but that's a lot of work for practically nothing. This is in agreement with the man page descriptions on the att universe of our Pyramid system. Note that the man page explicitly shows terminating the regcmp argument list with (char *) 0, and not NULL.