bug in nnrpd + solution [updated]

[Piotr Meyer]

On Wed, Apr 12, 2006 at 08:26:36PM +0200, Piotr Meyer wrote:

[...]

> After some test I found possible cause in "nnrpd/list.c":

Blame on me for sending untested suggestions. Finally, 
I have more free time to testing and saw my mistake:
Not "nnrpd/list.c" but "nnrpd/group.c" but rest are
correct - not "decimal" or "long decimal" but "unsigned"
(not "long unsigned"):


--- inn-2.4.2.orig/nnrpd/group.c        2004-12-22 05:21:19.000000000 +0100
+++ inn-2.4.2/nnrpd/group.c     2006-05-06 15:54:47.000000000 +0200

@@ -153,7 +153,7 @@
             if (count == 0)
                 Reply("%d 0 0 0 %s\r\n", NNTP_GROUPOK_VAL, group);
             else
-                Reply("%d %d %ld %ld %s\r\n", NNTP_GROUPOK_VAL, count,
+                Reply("%d %d %u %u %s\r\n", NNTP_GROUPOK_VAL, count,
                       ARTlow, ARThigh, group);
            while (OVsearch(handle, &i, NULL, NULL, &token, NULL)) {
                if (PERMaccessconf->nnrpdcheckart && !ARTinstorebytoken(token))

Some times ago I get question "why not unsigned long"? Answer is: becose
after putting "lu" unto code I get totally nonsese value in reply (so, it
isn't very strange). Now, some parts of my installation works very well
(no more negative values in low and hi):

...
group pl.soc.prawo
211 41398 2147603332 2147645183 pl.soc.prawo
article 2147645183
220 2147645183 <e3ka43$omo$1 at inews.gazeta.pl> article
...

But I also found similar, probably buggy, constructions (mapping low and hi 
marks to signed decimal) in other places:

nnrpd/list.c       
nnrpd/commands.c 
nnrpd/group.c      (another occurence)

-- 
Piotr 'aniou' Meyer