Leyne, Sean wrote:

>While it would be great to see the original document, it would seem that
>the "contract" represented in ibase.h (which has been around for a long
>time, back to IB 5.x -- at least) does not reflect the conditions which
>you outlined from the ORSI doc.
>

There is no conflict. Ibase.h is consistent with the OSRI
specification. As I quoted, a handled is an uninterpreted 32 bit
quantity. An SLONG, a ULONG, and a void* are all acceptable definitions
of handle. No OSRI compliant service makes an assumptions about the
declarations. All handles are passed by reference with "extern C" that
does not do type checking. (In fact, there is no way to define an
opaque 32 bit item.)

>And, Since ibase.h represents the API reality (like it or not) of the
>Firebird/IB world...
>

The reality is that they are 32 bit quantities that can be assigned and
passed as 32 bit quantities. There is no assumption that a handle is a
pointer, so no existing code can depend on handles being declared as
pointers. But this is not the case about handles being 32 bit quantities.

Perhaps the issue is not the declaration of handles but that Nickolay
has found it convenient to assume that their pointers in his
implementation? The last time this came up I gave him to the code to
map between handles and pointers.

>The question which needs to be focused on is how can the 32/64 bit
>handle issue be best addressed within the limitations of the current
>ibase.h definitions?
>

No, I don't think that is the issue at all. The architecture controls
(or at least should control) how extensions are to be handled. The
question is whether ibase.h defines a handle as an uninterpreted 32
quantity or as a pointer. The former is consistent with the
archtiecture, the later is not. The former allows code that was
implemented with the assumption that handles are 32 bit to continue to
work, the later allows Nickolay to get away with a cheap hack of no
significant.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376