vn under Microport System V/AT

[Bob McQueer]

>From article <402 at splut.UUCP>, by jay at 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.