Patch for .fifo problem

Hi,

I found the reason for the weird behaviour of .fifo... (Seemingly random
group names being printed when a client connected.) writefifo() was
comparing string pointers (which never changed) instead of the contents of
the strings. tin (and netscape) sends a long series of GROUP commands when
connecting, and every tenth group was printed to the fifo.

With my patch (see below) applied, it seems to work as intended. :)
(The patch is for 0.3.2)

I'm not sure I like this algorithm though. It requires that you read 2-3
articles from a group before it shows up in the fifo, and some small groups
get perhaps just 1 new article a day. :) I'd prefer to have it print the
name of the group the first time that an article is accessed, in order to
get real data on which groups are read. (Including the low-traffic ones.)

Is there any particular reason why writefifo() is called from the handlers
for GROUP, XOVER, XPAT and XHDR? I would think that calling it from the
commands that access (the body of) an article would be enough?

  - Patrik


--- commands.c.orig	Thu Jan 27 17:41:19 2000
+++ commands.c	Sun Mar  5 19:19:13 2000
@@ -133,12 +133,12 @@
 static void
 writefifo(void)
 {
-  static char * oldgroup = 0;
+  static char oldgroup[GROUPNAMELEN + 1] = { '\0' };
   static int interested = 0;
 
   if( NULL == currentgroup )return;
   if( -1 == fifo )return;
-  if( oldgroup == currentgroup ){
+  if( strcmp(oldgroup, currentgroup) == 0 ){
     interested++;
     if( 3 == interested % 10 ){
       int len;
@@ -149,7 +149,7 @@
     }
   }else{
     interested = 0;
-    oldgroup = currentgroup;
+    strcpy(oldgroup, currentgroup);
   }
 }
 

-- 
  Patrik Rådman  ·  patrik at iki dot fi  ·  http://www.iki.fi/patrik/
       "With sufficient thrust, pigs fly just fine."  -- RFC 1925