Re: [Imap-uw] 2006d Solaris 64 bit compile issues

[Bob]

Mark, Mark Crispin wrote: On Thu, 14 Dec 2006, Bob wrote: As for the problems in UW imap - I really think it is mainly an issue of trying to stuff 64 bits pointers into 32 bit integers. I'm sorry if I was unclear.  Let me be more specific: "Trying to stuff 64 bit pointers into 32 bit integers" is not the problem.  It is a snark.  As in "hunting a snark". There is no case in which a "64-bit pointer is stuffed into a 32-bit integer."  There are cases in which a 32-bit integer (actually a value of much lesser magnitude) makes a round trip to a 64-bit void* pointer and back again.  That's not the same thing, but the compiler doesn't know that.  In any case the round trip is successful. The cause of the problem is pointer alignment vs. endian.  It's architecture-dependent, not wordsize-dependent.  Compilers generally do not detect alignment/endian problems.  Such problems can only be found by exhaustive ferreting. I agree that this may be the case depending on how the data in question is being used in the program. Generally speaking though these issues can be avoided by careful type casting in the code. Perhaps it may be possible to supply gcc with an option that will 'fix' the way it compiles the app to compensate. I'm still researching this option. I don't even know what doesn't work.  I fixed the one thing that I know didn't work.  It's a lot easier to ferret when the ferret knows what the varmint smells like. We have found this issue to be completely unique to UW imap. Even the far more complex asterisk PBX package compiles and operates cleanly in 64 bit. What makes you think that Asterisk PBX wasn't developed/tested on 64-bit platforms? Because asterisk was developed over the last few years exclusively on 32 bit Lintel platforms with almost no work with regards to making it a 64 bit application. We are one of only a very few that has ported asterisk to Solaris and are running in production as a 64 bit application. It is impressive to me to see that such a complex application has worked correctly both in terms of the endian differences between Intel and SPARC and also as a 64bit application on SPARC. This tells me that some very tight coding standards have been maintained in order to be able to achieve this kind of portability as easily as we were able to. I'm not saying that there haven't been any Solaris portability issues (for instance, kernel vs. user based threading) but we haven't run into endian or 32 bit vs. 64 bit issues. BTW, we have contributed all of our Solaris portability fixes back to the asterisk project although Digium doesn't seem to be that interested in incorporating them hence the existence of the http://www.solarisvoip.com site which is independantly handling the Solaris porting issues. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. -- Bob Atkins   President/CEO Business Inter-net-working The Cure for the Common ISP! Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: [EMAIL PROTECTED]

begin:vcard
fn:Bob Atkins
n:Atkins;Bob
org:DigiLink, Inc.
adr;dom:Suite 408;;4676 Admiralty Way;Marina Del Rey;CA;90292
email;internet:[EMAIL PROTECTED]
title:President/CEO
tel;work:310-577-9450
tel;fax:310-577-3360
url:http://www.DigiLink.Net
version:2.1
end:vcard


_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw