Subject: int != pointer

From: John Dennis <[email-masked]>
Date: 13 Mar 2003 15:17:51 -0500

I'm building imap 2002b on an x86_64 machine (e.g. AMD Hammer) and the
compiler (gcc) defines an int as 32 bits wide and a pointer as 64 bits
wide. There seems to be a number of places where the code casts between
int and pointer, this should never be done as the two data types are not
necessarily compatible.

I'm willing to make the fixes and send a patch but I don't want to
duplicate the work of others if this has already been fixed. Has it?

John

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 13 Mar 2003 12:23:24 -0800 (PST)

The only places in which a cast is done between int and pointer is where the
pointer is a void*.  The void* is being used simply as a generic bucket that
is big enough to hold either a pointer or an int.

Since void* is larger than int, and since void* is used by this cast to
transport an int, but an int is never used to transport a void*; this is
completely alright.  There is nothing that needs to be fixed.

Once upon a time, it was accepted that if a programmer wrote an explicit cast
between two otherwise incompatible types, he knew what he was doing.

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Tue, 18 Mar 2003 15:08:55 -0800

I've got an intermittent problem with UW ipop3d on a Redhat6.0 box. 
Intermittently, if one logs in via pine, one will see a message similar to 
the following:

	message 3560 UID is 1 less than 10240

most of the time the numbers are not so far apart. This seems to have no 
impact on local pine users, but remote users (configured to leave mail on the 
server and only download new mail) who are using Pegasus Mail, usually find 
that the mail client will proceed to download all messages on the server 
after seeing this error, regardless of whether it has already downloaded the 
messages. 

Note I only noticed the error message in pine after a user started 
complaining about this problem. I have contacted the author of Pegasus Mail, 
but so far no joy on how to resolve the issue.

Any suggestions?
-- 
Harondel J. Sibble 
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
[email-masked] (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax)      (604) 686-2253 (pager)

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Mar 2003 15:14:46 -0800 (Pacific Standard Time)

> 	message 3560 UID is 1 less than 10240

This message occurs when a message has a X-UID header indicating that its
UID is less than the UID of the previous message in the mailbox.  This is
not a problem in POP, but is fatal in IMAP (which requires that UIDs be
strictly ascending).

What you need to find out is why this is happening.  Are the users using
some software other than Pine, ipop3d, or imapd?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Tue, 18 Mar 2003 15:56:44 -0800

On 18 Mar 2003 at 15:14, Mark Crispin wrote:

> This message occurs when a message has a X-UID header indicating that its UID
> is less than the UID of the previous message in the mailbox.  This is not a
> problem in POP, but is fatal in IMAP (which requires that UIDs be strictly
> ascending).
Hmm, I was afraid you'd say that.... Since I'd planned to enable imap again.

> some software other than Pine, ipop3d, or imapd?
Other than the above s/w, pegasus mail running under Win9x and Win2k, and 
very rarely kmail from MDK8.2 (like once in a few months).

Where do you suggest I look, logs don't show anything out of the ordinary.

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Tue, 18 Mar 2003 15:59:36 -0800

> problem in POP, but is fatal in IMAP (which requires that UIDs be strictly

In this case, fetchmail is polling the user's externally hosted pop3 mail and 
storing it locally (mbox), user logs on in the morning and downloads mail 
from local server.  I'm a bit foggy on this, but doesn't the X-UID header get 
written by sendmail on the local machine when it delivers the mail to the 
user's mbox file? Or is it done by fetchmail? Or somewhere else?

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Mar 2003 17:43:04 -0800 (Pacific Standard Time)

> user's mbox file? Or is it done by fetchmail? Or somewhere else?

The X-UID header should only be written by c-client based applications
(Pine, ipop3d, imapd).  Do you know if anything else is writing the
mailbox after a c-client based application processes it?

-- Mark --

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Tue, 18 Mar 2003 18:26:09 -0800

> mailbox after a c-client based application processes it?

No... that's the odd thing. Normally, fetchmail downloads mail, passes it to 
sendmail which dumps it into the user's mbox file. Users normally only 
connect via pop3 using Pegasus Mail.  Imapd is also running but is only used 
very rarely and only for testing purposes as Pegasus' imap capabilities are 
pretty minimal. There are only a handful of users on the system and I am the 
only one with shell access to the box.

Fetchmail downloads mail every 4 minutes, could that be a factor?

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Mar 2003 18:38:26 -0800 (Pacific Standard Time)

So, fetchmail is downloading the message from a POP3? IMAP? server to
another machine, and then users use POP3 to access mail on that machine?

Can you make sendmail filter out any X-UID headers in messages?  Maybe
that is the problem if they are somehow leaking out and then going through
fetchmail.

-- Mark --

---

From: "Harondel J. Sibble" <[email-masked]>
Date: Tue, 18 Mar 2003 19:30:35 -0800

> another machine, and then users use POP3 to access mail on that machine?
Yes fetchmail (on the local machine) is downloading from external pop3 
servers and passes mail to the local machines sendmail daemon which the 
delivers mail to the mbox files, all on the same machine.

> that is the problem if they are somehow leaking out and then going through
Hmm. That confuses me, I thought that X-UID is being written by c-client, so 
I'd assume that that header is not being written until after sendmail 
delivers it, being that fetchmail is not a c-client app.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 18 Mar 2003 22:42:03 -0800 (Pacific Standard Time)

> delivers it, being that fetchmail is not a c-client app.

This is to address the possibility that, somehow, there was an X-UID in
the incoming messages.  Before taking other measures it's a good idea to
make sure that this isn't happening.

-- Mark --