🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: demon.ip.support.pc
Article #752

Re: Snews etc, 2001-9-9

#752
From: Brian {Hamilton Kelly}
Date: Sat, 24 Jul 1999 00:00
97 lines
5287 bytes
On Friday, in article
     <19990723.2141.13703snz@roborat.demon.co.uk>
     dave@roborat.demon.co.uk "Dave Scott" wrote:

> On Friday, in article <19990723.0704.27411snz@dsl.co.uk>
>      bhk@dsl.co.uk "Brian {Hamilton Kelly}" wrote:
> ..
> > 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.

Aha!  That's not what John said, but it's more understandable :-)

> > 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...]

The code that *read* the u_time values (although they're not declared as
such, but simply as longs) does an atol() starting at buffer[18]; so long
as there's at least one space after the nine (or ten) digits, there's no
problem.  Is there?

> > 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!"

OK, so my conjecture wasn't completely crazy (unlike the original
author:-)

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

Surely we don't *want* to lose it?  Leave it in place for the present;
I'm (pretty) sure that writing a 10-digit time with "%09ld" ought[1] to
result in its writing ten digits; the subject will thereafter be found
starting at offset 29, with a space to boot.  If the current code
displays the subject, starting at offset 28 (with an initial space) and
yet manages to suppress that space in displays, then surely it can
suppress two of them?  (The 10-digit u_time occupying 18--27, followed by
the space from the /format/ string, and then the one from the original
Subject: line.)

Alternatively, the code could be changed to write "%08ld %08ld %010ld%s"
[2] and *rely* upon that spurious space; this would keep the <space +
subject> starting at offset 28.  Whilst u_time values are still nine
digits, there'd be a "spurious" initial '0' on the u_time value, but it's
only (I think) ever read with an atol() anyway.  On the third hand, the
format could go to "%08ld %08ld %010ld %s" and the ludicrous space before
the subject disposed of beforehand.  Whatever, the actual present .idx
files are not antagonistic to a 10-digit u_time; have I missed something
that *really* means that their format does need to change?

([1] Hmm; I *wish* I could think of what I've done with my Borland C
Programmer's Reference manual.)

[2] *can* one write "%010ld" to force a ten-digit quantity with leading
zeroes?

[3] Hmm[4].  Perhaps we should consider that these times are not unsigned
quantities; therefore when the u_time value exceeds 2^31-1, "printing"
them as "%010ld" will result in a leading negative sign.  Will SNews
still be around in another 30 years?[5]

[4] Unreferenced footnote

[5] Which is, of course, what all those COBOL programmers said back in
the late 1960s

-- 
Brian {Hamilton Kelly}                                         bhk@dsl.co.uk
    "But we're a university.  We /have/ to have a library!..."said Ridcully,
         "What sort of people would we be if we didn't go into the library?"
    "Students", said the Senior Wrangler, morosely. [TP: The Last Continent]
Technical Details
Message-ID: <19990723.2324.27418snz@dsl.co.uk>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <19990715.1824.42248snz@wash.demon.co.uk> <19990723.0704.27411snz@dsl.co.uk> <19990723.2141.13703snz@roborat.demon.co.uk>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fb525,6111b5a2a3d40d27
X-Google-Attributes: gidfb525,public
X-Google-Thread: 104dc3,59aa4a69c586739b
X-Google-Attributes: gid104dc3,public
From: bhk@dsl.co.uk (Brian {Hamilton Kelly})
Subject: Re: Snews etc, 2001-9-9
Date: 1999/07/24
Message-ID: <19990723.2324.27418snz@dsl.co.uk>
X-Deja-AN: 505196427
X-Mail2News-Path: news.demon.net!dragnhll.demon.co.uk
References: <19990715.1824.42248snz@wash.demon.co.uk> <19990723.0704.27411snz@dsl.co.uk> <19990723.2141.13703snz@roborat.demon.co.uk>
X-Trace: mail2news.demon.co.uk 932946272 mail2news:23477 mail2news mail2news.demon.co.uk
Organization: Dragonhill Systems Ltd
Newsgroups: demon.ip.support.pc,demon.ip.support.os2
X-Complaints-To: abuse@demon.net