RE: [Firebird-devel] 64/32 bit handle compatibility

[Samofatov, N. <Nickolay@BroadViewSoftware.com>]

Hi, Jim, All!

> We are talk about two related things: The interface=20
> architecture and the API.  One can write a program against=20
> either.  A program written against the interface architecture=20
> can expect a program to work against any version of a service=20
> on any platform.  A program written against a specific API or=20
> implementation can take advantage of implementation artifacts=20
> that are not portable across platforms, across=20
> implementations, or across versions.
>=20
> Let's take a specific example.  Suppose someone implemented a=20
> Firebird API in Java JNI as a thin layer.  A handle on the=20
> Java side of the interface would be a Java class with a=20
> private handle variable declared as a Java "int", which is 32=20
> bits.  The only translation necessary in the JNI code would=20
> be mapping the status vector into something that Java could handle.
>=20
> If properly coded against the Firebird architecture and the=20
> JNI specification, the native (ie C/C++ code) code should be=20
> completely portable.
>=20
> But if handles were 32 bits on some platforms, 64 bits on=20
> other platforms, and maybe something else on other platforms,=20
> nothing works.  Java doesn't have a concept of a datatype=20
> that is sometimes 32 bits and sometimes 64 bits, so=20
> presumably the Java class definitions would be held constant=20
> and the JNI interface code would have to be conditional.  But=20
> since you can't cram 64 bits into a 32 bit Java int, the=20
> interface code would have map handles, which requires a full=20
> bore mechanism to track state of interface objects.

You probably gave a valid argument this time. Jaybird currently assumes
handles are 32-bit quantities in native interface.=20
I would like Java and .NET people to say their word on topic.

> The choice is clear.  Handles should remain 32 uninterpreted=20
> types.  Ibase.h should be changed so handles are defined as=20
> typedefs of int.  The impacts are:
>=20
>=20
> 1.	Programs that use Firebird names for handles -- no impact.

Things are not so simple, as I already said. There is C++ method name
decoration which makes library interfaces incompatible even if you do
everything kosher.=20
There is also a lot of headers translated to plethora of languages by
hand from ibase.h which define handles as pointers.

If we decide to stick to 32-bit handles we need to define them as
something like this for current API to prevent problems with existing
client applications.
-----
#if defined(FB_USE_PORTABLE_HANDLE) || defined(_LP64) ||
defined(__LP64__) || defined(__arch64__) ......
typedef	int		isc_handle_type;
#else
typedef	void*		isc_handle_type;
#endif
-----

I.e. if application wants to get portable handle type it defines
FB_USE_PORTABLE_HANDLE before including ibase.h for now.

and as plain "int" for the next version of API distingushable with
-----
#define FB_API_VER 20
-----

Nickolay