Okay, here's a toughie for you... (maybe)

[Doug Gwyn]

In article <2784 at ux.acs.umn.edu> edh at ux.acs.umn.edu (Eric D. Hendrickson) writes:
>(btw -- if this is not a good question for comp.lang.c, please let me know)

It probably isn't a good idea to post a large chunk of source code and ask
the net to debug it for you..

>		if (p = (char *)strstr(line, grep)) { /* we have a candidate */

This cast bothers me.  If you put it there in an attempt to compensate
for strstr() not being declared in <string.h>, this isn't the right way
to do it.  Instead of allowing strstr() to be implicitly declared as
returning int and trying to fix it by applying a cast, you should
declare the function properly before using it:

	extern char *strstr();

>	return((char **)found);

Now here is probably the heart of your bug.  You should view all casts
with suspicion, since they indicate that you're trying to apply force
to an object to make it be something that is against its nature.
`found' is not actually a pointer to a pointer; it's an array of
arrays -- which is NOT AT ALL the same thing.  (I think Chris Torek
has a standard dissertation on this that he posts from time to time.)

>    gots = (char **)extract(grep);
>    for( ; **gots != (char)'\0'; printf("%s\n", gots++)) ;

And now the bug bites.  `gots' starts out pointing to found[0][0],
but with a weird type.  `*gots' would attempt to pick up a char*
from that address (for an operand of a second *), and of course
there is no char* datum stored there.  The other uses of `gots'
simply add confusion, and eventually something breaks from all
the use of invalid pointers to fetch stuff.