Re[4]: [Firebird-devel] FB 1.5.1

[Olivier M. <om...@ti...>]

On Fri, 16 Apr 2004 14:45:55 -0400,
"Samofatov, Nickolay" <Nickolay@BroadViewSoftware.com> wrote:

SN> > Shall I have to care or to know that in advance before 
SN> > writing and compiling my application ? Will my above 
SN> > hypothetic application (which worked perfectly before) 
SN> > miserably fails when connecting to a 64 bits incarnation of 
SN> > Firebird (a thing I can't know in advance just by looking at 
SN> > the server name) ?
SN> 
SN> No, Oliver. Your application will still work fine.
SN> It makes no difference if you connect from 32-bit or 64-bit client to
SN> 64-bit or 32-bit big- or little- endian server.

Pardon me to repeat, but I want this clear in my mind.

This means that as a 32 bits compiled client app. the "opaque" value
contained in a handle which I get from the API is no larger than a 32
bits quantity. And if that same handle on the server side needs more
bits (I doubt it needs) the remote protocol handles the translation.

Said differently, when I compile 32 bits code, my handles are physically
32 bits because that's what void* is, but that gives no problem as I'm
linked against a 32 bits version of the API library which can't give me
anything else than that. On the server code side, compiled in 64 bits
mode the void* might be 64 bits wide, but that is not an issue as by
agreed definition : numeric values of handles spans [0 -> 2^32-1] only.

Then any glue (the remote tcp/ip protocol or any other one) between the
client and the server code will marshall the values adequately.

A 64 bits clients would get 64 bits void* handle values from its 64 bits
client library. But yet, at the interface between client caller and
server callee, the handle quantity exchanged holds in a 32 bits value,
so that compatibility is okay from my 64 bits client to the 32 bits
server.

Right on all the line (maybe not on the implementation details) but on
the no-limitations side for both 32 and 64 bits clients and servers ?

Now, isn't this what Jim said by keeping void* definition but agreeing
the handle is no wider than a 32 bits quantity ? :)

-- 
Olivier Mascia <om...@ti...>