Samofatov, Nickolay wrote:

>6. REMOTE modules passed pointers over the wire in a number of places as
>32-bit quantities. I reviewed some such cases (which were indicated by
>warnings), but not sure that it was all such usages.
>

Nickolay, were there actual pointers passed over the wire or just handles?

There is an implicit assumption that "handles" (32 bit opaque things)
can be safely used as pointers. There are two ways we can go with this:

1. Define handles on 64 bit platforms to be 64 bit quantities
2. Stay with the definition of handles as 32 bit quantities and
perform a lookup to find the internal object

I think #2 is the smart option. There is no more cost to translating a
handle than to verify a handle. And while translation between 32 and 64
bit handles is restricted to the remote interface / remote server,
having a mixture of conventions is, I think, unwise.

Other than handler, what little horrors have creapt in?

>7. Reviewed places where ISC_STATUS was treated to be equivalent to
>SLONG and used to store pointers (ERRD_post and DYN_error were
>interesting, AFAIR).
>

I think the time has come to change the definition of ISC_STATUS from
SLONG to (void*). Better to stick a number into something declared as a
pointer than a pointer into something declared as an integer.

>
>
>2Jim: given this info, I'm sure you can repeat the exercise in 3 hours
>instead of 3 days of heavy debugging as I did. If you'll be building on
>LP64 Sun expect some problems with alignment (SIGBUS faults). I fixed
>many of them during LP32 UltraSparc port, but there are some remaining
>and some more will appear as a result of introducing of 64-bit pointers.
>AMD64 doesn't care about alignment much.
>
>
>

I've ported Interbase to Sparc before. I'm sure I can do it again. But
ask me again tomorrow.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376