RE: how far is SMP from being 64-bit clean?
"Horvath, Tom \(US SSA\)" <[email protected]> Fri, 16 Dec 2005 13:18:33 -0500
| Newsgroups | gmane.ietf.sfl |
|---|---|
| Message-ID | <[email protected]> |
Nick, We do realize that some of the SMP code currently makes assumptions about the size of certain types that will break when compiled using a 64 bit compiler. We are eventually planning a 64-bit port of the SMP libraries; however, the time frame has not yet been determined. We will keep the list informed as we decide upon a time frame. If prior to our decision anyone has contributions we will gladly accept them and try to incorporate them into the baseline if possible. Thanks, Tom Horvath BAE Systems IT [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nick Hudson Sent: Friday, December 16, 2005 11:37 AM To: [email protected] Subject: how far is SMP from being 64-bit clean? Has any qualification been done on the SMP libraries for 64-bit environments? I'm trying to build on SMP 2.5 on Fedora Core 3 x86_64, and although the build reports no obvious problems, I get errors at run-time which on inspection seem to be caused by the fact that there are some pieces of the code which are not 64-bit clean. For example: SRL_db.c has: SRLi_FlipLongs(le_data, numbytes >> 2); while the function definition in SRL_util.c is: void SRLi_FlipLongs(void *data, long numlongs) i.e. SRL_db.c is assuming that a "long" contains 4 bytes. Furthermore, inside SRLi_FlipLongs(), there is various manipulation going on which also seems based on the assumption that a "long" is made up of 32 bits. A cursory look through the code suggests that there is quite a lot of usage of "long"s, many of which appear to have similar problems. So I wondered whether there's anything going on with 64-bit ports, or whether anyone has a feel for how pervasive these problems might be? thanks nick