Re: rfc822 date handling in imap4d/util.c

[Alain Magloire]

> 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