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