Potential problem and patch: IMAP 2.2.8

[Nikola Milutinovic]

Hi all.

Cyrus IMAP 2.2.8
Tru64 UNIX 5.1B
Native CC

I was just compiling Cyrus IMAP 2.2.8 and due to some other problems 
(Tru64 oddities), I payed close attention to the compilation process. I 
noticed a potentially problematic warning:

cc: Warning: cyrusdb_quotalegacy.c, line 531: In this statement, the 
referenced type of the pointer value "&datalen" is "unsigned long", 
which is not compatible with "int". (ptrmismatch)
         r = myfetch(db, globbuf.gl_pathv[i], &data, &datalen, tid);
----------------------------------------------------^

As you can see, a pointer to "long" (actually "size_t") is being passed 
as a pointer to "int". This is problematic on Tru64 UNIX, since size of 
"long" is 64bit, while "int" is 32bit. From my point of view it is 
problematic in any case, so I made a simple patch:

*** lib/cyrusdb_quotalegacy.c.orig      Wed Aug  4 13:38:36 2004
--- lib/cyrusdb_quotalegacy.c   Wed Aug  4 13:46:00 2004
***************
*** 526,532 ****

       for (i = 0; i < globbuf.gl_pathc; i++) {
         const char *data, *key;
!       size_t keylen, datalen;

         r = myfetch(db, globbuf.gl_pathv[i], &data, &datalen, tid);
         if (r) break;
--- 526,532 ----

       for (i = 0; i < globbuf.gl_pathc; i++) {
         const char *data, *key;
!       int keylen, datalen;

         r = myfetch(db, globbuf.gl_pathv[i], &data, &datalen, tid);
         if (r) break;

I haven't tested it, but I'm sure it will work, while I can't say for 
sure if the unpatched version would work or break. The bug manifesting 
would depend on whether the system is small-endian or big-endian and 
only if "long" and "int" have a different size. I'm not really sure if 
Alpha is big- or small-endian.

Nix.
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html