bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rfc822 date handling in imap4d/util.c


From: Sam Roberts
Subject: rfc822 date handling in imap4d/util.c
Date: Thu, 14 Jun 2001 23:48:11 -0400
User-agent: Mutt/1.3.16i

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
it's in the right direction.

Overview:

- Some sscanf() formats weren't matching the arguments.

- Some TZ stuff wasn't implemented.

- util_parse_header_date(), parses rfc822 dates, but only some.

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

Sam

p.s.

This appears to be becomeing the official GNU mailutils greeting, so
what do you guys think? Fight the unilingualism of POP3 servers!

Index: pop3d.c
===================================================================
RCS file: /cvsroot/mailutils//mailutils/pop3d/pop3d.c,v
retrieving revision 1.30
diff -u -r1.30 pop3d.c
--- pop3d.c     2001/05/20 14:57:56     1.30
+++ pop3d.c     2001/06/15 00:19:24
@@ -280,7 +280,7 @@
   }
 
   /* Lets boogie.  */
-  fprintf (ofile, "+OK POP3 Ready %s\r\n", md5shared);
+  fprintf (ofile, "+OK Bonjour, POP3 Ready %s\r\n", md5shared);
 
   while (state != UPDATE)
     {

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)

++++++++++++++=


Index: mailbox/mbx_imap.c
===================================================================
RCS file: /cvsroot/mailutils//mailutils/mailbox/mbx_imap.c,v
retrieving revision 1.29
diff -u -r1.29 mbx_imap.c
--- mailbox/mbx_imap.c  2001/06/01 05:59:29     1.29
+++ mailbox/mbx_imap.c  2001/06/15 03:29:53
@@ -1230,6 +1230,58 @@
   return status;
 }
 
+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.

  Also implemented the timezone, I think.



 static int
 imap_envelope_date (envelope_t envelope, char *buffer, size_t buflen,
                    size_t *plen)
@@ -1238,12 +1290,12 @@
   msg_imap_t msg_imap = message_get_owner (msg);
   m_imap_t m_imap = msg_imap->m_imap;


   This was useing buffer as a temp buffer for the imap command, then
   putting ctime into it, this seems wrong. Also, plen was getting
   set to the length of the imap response, not the ctime() format string
   that was actually being put into the buffer.

+    /* FIXME: I don't know what strftime does if the buflen is too
+       short, or it fails. Assuming that it won't fail, this is my guess
+       as to the right thing.
+     
+       I think if the buffer is too short, it will fill it as much
+       as it can, and nul terminate it. But I'll terminate it anyhow.
+     */

 
Index: imap4d/imap4d.h
===================================================================
RCS file: /cvsroot/mailutils//mailutils/imap4d/imap4d.h,v
retrieving revision 1.19
diff -u -r1.19 imap4d.h
--- imap4d/imap4d.h     2001/06/01 19:52:05     1.19
+++ imap4d/imap4d.h     2001/06/15 03:29:54
@@ -68,6 +68,8 @@
 # include <paths.h>
 #endif
 
+#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.

Index: imap4d/util.c
===================================================================
RCS file: /cvsroot/mailutils//mailutils/imap4d/util.c,v
retrieving revision 1.22
diff -u -r1.22 util.c
--- imap4d/util.c       2001/06/12 00:40:58     1.22
+++ imap4d/util.c       2001/06/15 03:29:57
@@ -16,7 +16,6 @@
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
 
 #include "imap4d.h"
-#include <ctype.h>
 
 static int add2set __P ((size_t **, int *, unsigned long));
 static const char *sc2string __P ((int));
@@ -199,7 +198,7 @@
              /* Copy stuff */
              s = p + 2;
              p = q;
-             while (*q++ = *s++)
+             while ((*q++ = *s++))

     -Wall warns, so keep gcc quiet.

 int
 util_parse_internal_date0 (char *date, time_t *timep, char **endp)
 {
-
-  memset (&tm, 0, sizeof (tm));
-  n = sscanf (date, "%2d-%3s-%4d %2d:%2d:%2d %5s%n\n",
-             &day, mon, &year,
-             &hour, &min, &sec, &tzs, &off);

    Format bug.

+  if(imap_parse_date_time(datep, &tm))

    Use the better code in mailbox.

    
 int
 util_parse_header_date (char *date, time_t *timep)
 {

   This will get fed rfc822 Date: headers, so use the parse822 function.

 int
-util_parse_rfc822_date (char *date, time_t *timep)
+util_parse_ctime_date (char *date, time_t *timep)
 {

   This doesn't parse RFC 822 dates, so renamed it.

 
@@ -916,12 +807,12 @@
   char *name;
   int flag;
 } _imap4d_attrlist[] = {
-  "\\Answered", MU_ATTRIBUTE_ANSWERED,
-  "\\Flagged",  MU_ATTRIBUTE_FLAGGED,
-  "\\Deleted", MU_ATTRIBUTE_DELETED,
-  "\\Draft", MU_ATTRIBUTE_DRAFT,
-  "\\Seen", MU_ATTRIBUTE_SEEN,
-  "\\Recent", MU_ATTRIBUTE_RECENT,
+  { "\\Answered", MU_ATTRIBUTE_ANSWERED },
+  { "\\Flagged",  MU_ATTRIBUTE_FLAGGED },
+  { "\\Deleted", MU_ATTRIBUTE_DELETED },
+  { "\\Draft", MU_ATTRIBUTE_DRAFT },
+  { "\\Seen", MU_ATTRIBUTE_SEEN },
+  { "\\Recent", MU_ATTRIBUTE_RECENT },
 };

   -Wall generated annoying warnings.
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]