> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Roman Rokytskyy
> Sent: Martes, 26 de Julio de 2005 17:03
> Also, at least in FB 1.5, all
> needed information was already stored in the TLS (if I remember
> correctly that was TDBB structure, parts of which were for example
> passed into the UDF together with parameter descriptor to provide a
> possibility to access the BLOB fields, though I was reading FB sources
> more than year ago, so some inconsistencies/errors might be present).

There's a TDBB structure, but it's not passed to the UDF.
UDFs receive data in four ways. One way is through descriptors. The other is
a special construction for arrays (only for reading them). Another is the
typical of parameter by reference (you receive pointers to char, to int,
etc.). The fourth is when you want to receive a parameter of type blob, the
engine will wrap the internal indentifier in a structure that has three
pointers to functions. Those pointers are filled with the addresses of
callbak-safe functions that reside in the engine (get, put, seek). The
wrapper structure also gets a copy of the internal blob id as a handle (if
the blob field was NULL, an empty blob is created and such id is provided as
handle). No more context is provided.

In FB2, Nickolay created two built-in UDFs that allow to get system
variables and get/set user variables and they are based on TLS, but this is
another story (functions.cpp inside jrd).

C.