Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4042
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <00b001c364af$466da0f0$1b02000a@mitch>
To: =?ISO-8859-15?Q?Marcus_B=F6rger?= <helly@php.net>
Cc: <internals@lists.php.net>
References: <20030817101510.93381.qmail@pb1.pair.com> <1659985422.20030817121803@post.rwth-aachen.de>
Date: Sun, 17 Aug 2003 13:04:05 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 64-bit zval type
From: ard@ard.nu ("Ard Biesheuvel")

> AB> Is there a 64-bit integer zval, or is it expected in the near future ?
> AB> (Need it for BLOB handling in Interbase)
>
> Only on 64bit machines there is.

You mean because long == int64 on 64-bit architectures, right ?

> But you can use mumeric strings for that as ext/pgsql does.

Not really, in my case.

Right now, if you create a BLOB, the C-struct describing it internally is
cast
to a zval_string and returned to user-space. I think this is bad. Apart from
the
fact that you get memory adresses and stuff in the script context, it also
means
that the value returned has no meaning whatsoever to Interbase itself.
Furthermore, if you try to insert a BLOB-value directly that has exactly the
sizeof(C-struct), it will be cast as such, and a bogus BLOB handle will be
inserted into the database.

I would like to improve this by returning the Interbase-assigned BLOB
handle directly. The stuff from the struct would have to be stored in a
map<handle,C-struct>, probably implemented by using a hash. The size
of a BLOB-handle is 64-bits. (Although currently implemented as a struct
containing two int32's in Interbase)

However, currently Interbase supports inserting strings into BLOB fields
directly (which is very useful, BTW, apart from the abovementioned pitfal).
If I use strings to represent BLOB handles as well as BLOBs themselves,
I would have to distinguish between a BLOB handle and the BLOB itself
by looking at the string. If the handle would be a real int64, that wouldn't
be
a problem.

Ard