[17055] in Athena Bugs
Greg Stark: Discuss bugs
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Aug 12 22:03:26 1999
Message-Id: <199908130203.WAA09797@rcn-sucks.fsck.com>
To: bugs@MIT.EDU
Date: Thu, 12 Aug 1999 22:03:12 EDT
From: Greg Hudson <ghudson@MIT.EDU>
------- Forwarded Message
Received: from SOUTH-STATION-ANNEX.MIT.EDU by po10.MIT.EDU (5.61/4.7) id AA12140; Thu, 12 Aug 99 19:17:12 EDT
Received: from sparkle.Generation.NET by MIT.EDU with SMTP
id AA07542; Thu, 12 Aug 99 19:16:47 EDT
Received: from x2-492.mtl.Generation.NET (brnstndkramden.acf.nyu.edu@x2-492.mtl.Generation.NET [209.205.11.147])
by sparkle.Generation.NET (8.9.3/8.9.3) with SMTP id TAA29642;
Thu, 12 Aug 1999 19:17:08 -0400 (EDT)
Sender: stark@x2-492.mtl.Generation.NET
To: discussers@MIT.EDU
Cc: bug-discuss@MIT.EDU
Subject: Discuss bugs
From: Greg Stark <gsstark@MIT.EDU>
Date: 12 Aug 1999 19:16:52 -0400
Message-Id: <87u2q4k2sb.fsf@x2-492.mtl.Generation.NET>
Lines: 40
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
A couple years ago I wrote nndsc, a Gnus backend for discuss. In doing so I
turned up a few edsc bugs that I never reported. Since one of them is a y2k
bug I was recently reminded that I ought to have reported these.
1) Dates after 1999 will be printed wrong, eg:
07/29/:6 01:36
This is a tricky one because changing to a four digit date could mess anything
which parses dates. Though I don't know if anything actually does parse the
header of discuss transactions except nndsc which would handle any of the
following formats:
07/29/1996 01:36
07/29/106 01:36
07/29/2006 01:36
2) There's a file descriptor leak in gtf which rapidly causes edsc to run out
of file descriptors. I think this leak is only present if it's compiled with
cacheing enabled, but I don't recall exactly.
This is quite severe but I would guess discuss.el doesn't use that method or
this would have been reported before.
3) The last parameter to the results of gti for dsmail transactions is not
quoted properly. In fact it's not quoted at all. This means that if an
e-mail address for a dsmail transaction contains a double quote in it it
will cause an error when discuss.el tries to read the line.
Unfortunately this last one is a really tricky problem. Fixing it is easy but
if you fix it you'll have to bump the protocol version otherwise you'll break
anything that has a work-around for the problem. Unfortunately the protocol
version currently is two different numbers depending on whether edsc is
compiled with caching. To do this properly you probably have to remove the
option for caching to be enabled, or you could just declare that you can't
test for caching by protocol number. Presumably you would have gtfc return an
error or work but print a warning if it's compiled without caching.
- --
greg
------- End of Forwarded Message
