🚀 go-pugleaf

In article <19990724.1417.42340snz@wash.demon.co.uk>
           john$@wash.demon.co.uk "John Washington" writes:

> On Friday, in article
>      <19990723.2141.13703snz@roborat.demon.co.uk>
>      dave@roborat.demon.co.uk "Dave Scott" wrote:
> 
> DS> On Friday, in article <19990723.0704.27411snz@dsl.co.uk>
> DS>      bhk@dsl.co.uk "Brian {Hamilton Kelly}" wrote:
> DS> ..
> DS> > On Thu, 15 Jul 1999 19:24:30 +0100 (BST), in article
> DS> >      <19990715.1824.42248snz@wash.demon.co.uk>
> DS> >      john$@wash.demon.co.uk "John Washington" wrote:
> DS> ..
> DS> > But more importantly, look at the offset at which the title itself
> DS> > starts: 29.  This means that there is ALREADY room for the 10-digit
> 
> Perhaps.  In which case the code still needs modifying, but we
> might get away without changing the .idx format.

I could be being my usual simplistic self here, but is all
this file/directory renaming really necessary?  I've been
away on hols for a week (which is why I haven't chipped in
so far) and whilst I think I picked up all the articles it's
possible I've missed something obvious in the "catching up".

ISTM that if the .idx files are the main (only?) problem
the necessary fix is straightforward - just make the code
that reads them a little less fickle.  All it needs is a
few fscanfs or strtoks instead of the "buff + 28" type of
code - OK, it's a bit slower than using fixed offsets but
does allow a more flexible approach.  It's not as though
the .idx entries are fixed length records (ie. allowing one
to calc offsets by recnum x reclen) as the Subject: bit is
variable length.

No "one off" conversion needed; the .idxs will gradually
expand to handle the 10 digit time fields as necessary -
AFAICS the only downside is that the newsbase will become
unreadable by older versions of Snews/Unbatch etc.

Unless, of course, I'm missing something fundamental...

[snip..]

> DS> between the colon and the field's contents, i.e. it comes from :-
> DS>         Subject: Re: Corrosion of metal miniatures
> DS>                 ^...here
> DS> 
> DS> Indeed there's no need to store that space in the .idx file - there's a
> DS> comment in John's version of eat_gunk() (see snews.c) that :-
> DS>     "...the call to this function always passes a buffer that
> DS>     starts with a space!"
> DS> 
> DS> However, whether we could lose it without affecting the existing
> DS> versions of all the utils or not.... ?
> 
> It's tempting to lose it,

And maybe rationalise the '\n' handling at the same time...

>                     but I have a vague memory that it's already
> been hijacked.  I don't recall whether I saw it in news/mail or
> where, but I have an idea there's sometimes an asterisk there.
> 
> Perhaps in CppNews?
> 
> Speaking of which, I suppose I'd better add those guys to the
> cross-posting.  I mean, they probably get so much traffic over
> there, they don't have time to subscribe to dis.pc as well. :-)

:-)  And speaking too of which, this whole subject seems to
me to be a dev issue - I was tempted to set f-u's to d.i.d
but didn't on the grounds that (I guess) the readership
there would be smaller.

> And, just so they don't think this posting is off-topic for
> dis.cppnews, should I add details of my latest money-making
> pyramid scheme, adult web site and fat-burning offer?  :-)

Don't forget the zillion-name email address list ;-)
-- 
Pete
demon.ip.support.pc is for discussion of IP-related issues using plain
DOS software - *not* PC hardware, Windows, Netscape, Turnpike, IE4/5...
Read the "Which Group" FAQ:- ftp.demon.co.uk/pub/doc/general/whichgrp.faq