well that makes sence. I belive solaris figures out the uint32 as it is
really emulating 32bits on the 64bit kernel. I did some reading and it
seems that dbmail as a whole may not benifit much from accualy being
compiled 64bit, in fact it may make it slower. What is your test showing?
I am glad at
Actually, I was reading some more, and it looks like the standards all mandate
that int is 32 bit. The confusion is regarding long and long long where
long is 32 bit on a 32 bit machine and 64 bit on a 64 bit machine and long
long is 64 bit on a 32 bit machine and is usually not even defined on 64
odd, just checked with your same chars pasted into the test app:
jsdf;kljasdf
asdf
sun sparc 64 (no change to header)
dc0778f4e49bd14622a016e705cbdb15
changed header:
0988915eac85ce5fed09f29252b0cc7f
sun sparc 32 bit (no header change)
I'm getting the adb... on both the Opteron and my Pentium, both with
typedef unsigned int uint32
So I wonder if we have an endianness issue, too... I've got a Sparc at school,
I'll give it a whirl on that machine, too. And my Alpha is out of reach again,
so I can't double check the results on it
The answer is simple... the tags BYTE_ORDER are not specified on sparc
because sparc doesn't have endian.h, simple fix
add to md5.h
#ifdef __sparc
#define LITTLE_ENDIAN 1234
#define BIG_ENDIAN4321
#define BYTE_ORDER BIG_ENDIAN
#endif
and them it works perfectly I get adaXXX on both 64bit
The rudiments of Sieve support are already in place in 2.0, but only enough so
that I had a basis to understand how to write the new delivery chain with
hooks built in to support multiple sorting backends. During 2.1 development,
I'm going to finish the Sieve support connector to the libSieve
