[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rfc822 date handling in imap4d/util.c
From: |
Alain Magloire |
Subject: |
Re: rfc822 date handling in imap4d/util.c |
Date: |
Fri, 15 Jun 2001 09:34:19 -0400 (EDT) |
> Bonjour!
>
> I noticed some problems with date parsing in imap4d/.
>
> I've put a kind of annotated patch below, and attached a real patch.
>
> It compiles, but isn't tested. I don't really know how to exercise
> the imap server to do this, so I wouldn't patch blindly, but I think
- You will have to be root.
- You could started on stdin but you will have to know the
IMAP4 protocol i.e. sends the "a00 login sroberts xxxx" etc ..
- Run it as a deamon 'imap4d -d' and use your prefer
browser
> it's in the right direction.
>
> Overview:
>
> - Some sscanf() formats weren't matching the arguments.
oops.
>
> - Some TZ stuff wasn't implemented.
It was tricky, not all platforms carry TZ. For example
strftime () --> %Z not supported everywhre. timezone and
tzname are provided as globals on many platform but I do not
think it was required in POSIX nor ANSI C.
>
> - util_parse_header_date(), parses rfc822 dates, but only some.
Ok.
>
> - util_parse_rfc822_date(), confusingly, doesn't parse RFC
> 822 dates, it parses the ctime format, used in the From_ of mboxes.
>
> +++
>
> The parsing of ctime() dates is useful, maybe it should move to
> mailbox, since this is what is returned by envelope_get_date().
> Alternately, envelope_get_date() could return an RFC 822 date
> (the date would always be in UTC, +0000).
>
> This makes me think, perhaps the envelope date should be returned in
> RFC 822 format, instead of ctime? Just a suggestion,
And a good one, those bits of common/usefull pieces should be move
back to the mailbox for sharing.
> I'm not sure
> what people are using the date for. However, it's likely they'd want
> to compare to rfc822 format, maybe we should provide wrapper functions
> to transform between struct tm, and time_t (UTC), ctime, rfc822 date-time,
> imap internal-date. Most of these pieces are there, but not all, and
> not all exported to users of mailutils.
I would vote for this, sharing.
>
> This appears to be becomeing the official GNU mailutils greeting, so
> what do you guys think? Fight the unilingualism of POP3 servers!
8-)
My phone line is down so I can not commit nor test... However I think that
Sergey commited some of your patches.
> +int
> +imap_parse_date_time (const char **p, struct tm *tm)
> +{
>
> Pulled the code out so it could be linked by imap4d, since imap4d's
> implementation of this had sscanf bugs, and was essentially identical.
>
> It should be prototyped, but I don't know what the plan for sharing
> this kind of stuff is.
Did not you have plan for some sort of date_xxx() API?
> +#include <ctype.h>
> +
>
> isspace() was used somewhere but not prototyped. So I put this
> here. Then I noticed the whole library lacks prototypes. Probably
> this is so annoying that -Wall isn't used, thus gcc didn't report
> sscanf() mismatches.
If possible, functions should be prototyped, if not send email and patch.
Some other functions like strtok_r() or strcasecmp ()
part of libmailutils/*.c support files for some platforms
are more tricky since having prototypes can be in conflict
for others.
--
alain