🚀 go-pugleaf

On Friday, in article <19990723.0704.27411snz@dsl.co.uk>
     bhk@dsl.co.uk "Brian {Hamilton Kelly}" wrote:
..
> On Thu, 15 Jul 1999 19:24:30 +0100 (BST), in article
>      <19990715.1824.42248snz@wash.demon.co.uk>
>      john$@wash.demon.co.uk "John Washington" wrote:
..
> > However, the index file for each newsgroup is made up of
> > fixed-format records and the count is stored in them at
> > offset 28.  This is the only problem.  Ka9q doesn't have any
> > such problem.  DIS?  Anyone capable of reading the source of
> > DIS is unlikely to do it for free, as Chris recently said.
> > PcElm, <shrug> <oi vay>.  No source, no comment.
> 
> Offset 28????  Unless I'm looking at something different from you, I make
> it offset 18; was that a slip of the finger?
> 
> For example, here is a line chosen at random from an .idx file here:
>     00025537 00003308 932245580  Re: Corrosion of metal miniatures
>     0         1         2         3         4         5
>     012345678901234567890123456789012345678901234567890etc
>     
> See?  Offset 18.

18 to the timestamp, 28 (see below) for the next field, the subject.

> But more importantly, look at the offset at which the title itself
> starts: 29.  This means that there is ALREADY room for the 10-digit
> u_time, and its trailing space.  See the TWO spaces that follow the
> present 9-digit u_time.

[snip...]

> I've checked the code: it's very strange, because in UNBATCH and EXPIRE,
> the code that writes the revised index record has format 
>         "%08ld %08ld %09ld %s"
> so whence cometh the double space that I see in my index files?  Surely
> there cannot be a space at the beginning of the subject line (that's
> written with the %s???)  Something's decidely fishy.

I believe (99% confidence after checking in unbatch), it's the space
between the colon and the field's contents, i.e. it comes from :-
        Subject: Re: Corrosion of metal miniatures
                ^...here

Indeed there's no need to store that space in the .idx file - there's a
comment in John's version of eat_gunk() (see snews.c) that :-
    "...the call to this function always passes a buffer that
    starts with a space!"

However, whether we could lose it without affecting the existing
versions of all the utils or not.... ?

-- 
    ()---()
     (0 0)    Dave Scott   e-mail: dave@roborat.demon.co.uk
----m-( )-m-------------------------------------------------------------
      =o=