mjy@sdti.UUCP (Michael J. Young) (11/03/88)
Well, I've successfully installed Elm 2.1-PL1 under Microport System V/AT
Version 2.4, and it's great! Much more portable than 1.5 was! The only
two problems I had were a buggy curses under System V/AT 2.4 (which was
cured by restoring the 2.3 curses library) and a buggy optimizer that generated
bad code (sigh).
However, I received a message last night with an expiration header in it:
Expires: 16 Dec 88 06:25:xx (I don't remember the time!)
When Elm displayed the mailbox status, it said the message was expired. Now,
last I checked, December 16 was AFTER November 3, so I started looking
at the code in expires.c.
The code in here can only be called strange. The first symptom was that
process_expiration_date() parsed the date as if it were in form #1, when
it clearly is in form #4.
Secondly, looking at the code, I see funny things. Like, for example,
around line 88, is the following fragment:
if (strlen(word2) == 0) { /* we have form #6 or form #5 */
if (isdigit(word2[1]) && isdigit(word2[2])) /* form #6! */
.....
If the length of word2 is 0, why should the code be poking around after
the end of the string?!
What's worse, the entire rest of the date parsing code seems to forget
about the fact that there is a time field in the date.
For my specific date format, the problem is that word4 actually contains
the time, and this confuses the code into thinking the date is in
the format of form#1.
I'll leave the fixes to the Elm gurus. In the meantime, I've inserted
a "return" statement in a well-placed location at the beginning of the
function. I've lived without this feature for a long time, I can do
without it until Patch#2 comes out! :-)
--
Mike Young
Software Development Technologies, Inc., Sudbury MA Tel: +1 508 443 5779
Internet: mjy@sdti.sdti.com UUCP: {harvard,mit-eddie}!sdti!mjy