Hi, Jim!

> The question at hand in Firebird is handles. To quote from
> the "OSRI Reference Manual" published 28 March 1991 by the
> Interbase Software Corporation, page 9:
>
> "The call interface is: ... Handle-based. OSRI objects that use
> handles are database attachments, transaction, compiled requests,
> and active blobs. These objects are formally created and
> destroyed,
> and are represented by handles during the course of their active
> state. No object is global, and all state information resides in
> these objects.
>
> Note [with double boxed border] A handle is an
> uninterpreted 32-bit
> quantity. Programmers should not make any assumptions
> about what it is.

Is anyone here had been writing applications according to this document
in the past 5-8 years?

>
> Handles were 32 bit uninterpreted quantities on 32 bit
> systems and 32 bit uninterpreted quantities on 16 bit systems.
>
> The Interbase/Firebird include files defined handles as
> pointers, which on 32 bit systems is completely consistent
> with the architecture on 32 bit systems. They could just as
> well have been defined as longs or unsigned longs.

But note they are not defined this way.

> There are two way to resolve this. One is to analyze the
> user impact of changing the handle from 32 bits to 64 bits
> when compiling for 64 bits.
> Most user code will need a conversion anyway, and if users
> where careful to use the optional handle types rather than
> the official architecture, their code should work pretty much
> unchanged.
>
> Or, that this is an architecture. It is a contract we made
> with our users. If we need to change something covered by
> the architecture, we will extend the architecture, not break it.

I'm afraid that contract we have with users is written in ibase.h
header.

> There may, in fact, be no existing user code that passes
> handles around as explicit 32 bit quantities. Trying to
> determine whether there are and if so what the impact of a
> proposed incompatible change is the wrong answer. The right
> answer is "that's the way we defined it; that the way it will work."

To the best of my knowledge all portable implementations act according
to a public API contract outlined in ibase.h.

> Vulcan is not yet in compliance with the architecture, but
> will be when it ships. If a program written against the OSRI
> specification and the Firebird Vulcan API is linked and run
> with the proposed Firebird 1.5.1 API, it will crash and burn.
> If a program was written against the OSRI specification
> preserves only 32 bits of a 64 bit handle, it will work on
> some platforms and implementation and fail on other platforms
> and implementations.

An application written according to Firebird architecture and ibase.h
contract will be compatible if built and linked against Vulcan (of
course, after fixing possible build and linkage errors).

> Borland had a very low regard for architecture, but respected
> it nevertheless. I expect more from the Firebird project.
>
> I urge the Firebird admins and the Firebird 1.5.1 release
> managers not to ship code that violates our own published
> architecture.

ibase.h ?

Ok, I can explain further.

Changing handle type from pointer to integer requires changes in almost
every application compiled against ibase.h because (1) pointer printf
format is different, (2) pointer to pointers assignments to pointers to
integers are hardly not compatible in most compilers so handle var
arguments will be broken in user applications, (3) pointer to integer
assignments are incompatible with most modern compilers too, some
produce warnings (GCC, IC, MSVC), and some errors (Sun Forte and some
other vendor compilers), (4) type name decorations for integer and
pointer are _different_ so API change will result in linkage errors in
existing applications and libraries.

Do you want to change handle type unconditionally and force everyone to
fix their applications right now or do so conditionally in 64-bit case
only and compicate writing of portable applications?

> Jim Starkey

Nickolay