Subject | UDF parameters bug |
---|---|
Author | Helmut Steinberger |
Post date | 2003-11-18T12:08:15Z |
Hello,
I think I discovered a bug, when using UDFs.
I use several UDFs, which I build by myself. Until I changed to FB1.5
all UDFs worked well as expected, but now I discovered a strange
behavior.
I think the datatype of the paramters passed to the UDF are
interpreted wrong.
The first and second parameter is interpreted right, but every further
parameter is interpreted as the same type like the 2nd parameter.
I give you an example to understand what I meen:
The Pascal Code of the UDF :
function test_udf (var intparam : integer;
var intparam2 : integer;
var doubleparam : double) : double; stdcall;
begin
doubleparam := (doubleparam + intparam + intparam2) / 2;
result := doubleparam;
end;
The UDF is declared to FB like that:
DECLARE EXTERNAL FUNCTION TEST_UDF
integer,
integer,
double precision
RETURNS double precision BY VALUE
ENTRY_POINT 'test_udf' MODULE_NAME 'testlib'^
When I pass the following statement
select test_udf (1, 2, 2.9) from rdb$database in EMS Interbasemanager
I get the correct result 2.95
When I now change the statement to
select test_udf (:a, :b, :c) from rdb$database
I will be asked to enter the 3 parameters.
I enter 1 for :a, 2 for :b and 2.9 for :c then I get the result 2.5
The Reason for that wrong result is, that the 3rd parameter is
interpreted as an integer value and so the decimals are cut of and so
it will be 2 instead of 2.9
I made several further tests, and discovered, that all parameters
after the 2nd one, will be interpreted as the same datatype like the
2nd.
For Example if you have an UDF with 7 parameters like that:
DECLARE EXTERNAL FUNCTION TEST_UDF
integer,
date,
integer,
char (10),
double precision,
timestamp,
double precision
RETURNS double precision BY VALUE
ENTRY_POINT 'test_udf' MODULE_NAME 'testlib'^
The first one will be integer, the 2nd one date and every further
parameter will also be date.
I use FB 1.5 RC7
cu
Helmut
I think I discovered a bug, when using UDFs.
I use several UDFs, which I build by myself. Until I changed to FB1.5
all UDFs worked well as expected, but now I discovered a strange
behavior.
I think the datatype of the paramters passed to the UDF are
interpreted wrong.
The first and second parameter is interpreted right, but every further
parameter is interpreted as the same type like the 2nd parameter.
I give you an example to understand what I meen:
The Pascal Code of the UDF :
function test_udf (var intparam : integer;
var intparam2 : integer;
var doubleparam : double) : double; stdcall;
begin
doubleparam := (doubleparam + intparam + intparam2) / 2;
result := doubleparam;
end;
The UDF is declared to FB like that:
DECLARE EXTERNAL FUNCTION TEST_UDF
integer,
integer,
double precision
RETURNS double precision BY VALUE
ENTRY_POINT 'test_udf' MODULE_NAME 'testlib'^
When I pass the following statement
select test_udf (1, 2, 2.9) from rdb$database in EMS Interbasemanager
I get the correct result 2.95
When I now change the statement to
select test_udf (:a, :b, :c) from rdb$database
I will be asked to enter the 3 parameters.
I enter 1 for :a, 2 for :b and 2.9 for :c then I get the result 2.5
The Reason for that wrong result is, that the 3rd parameter is
interpreted as an integer value and so the decimals are cut of and so
it will be 2 instead of 2.9
I made several further tests, and discovered, that all parameters
after the 2nd one, will be interpreted as the same datatype like the
2nd.
For Example if you have an UDF with 7 parameters like that:
DECLARE EXTERNAL FUNCTION TEST_UDF
integer,
date,
integer,
char (10),
double precision,
timestamp,
double precision
RETURNS double precision BY VALUE
ENTRY_POINT 'test_udf' MODULE_NAME 'testlib'^
The first one will be integer, the 2nd one date and every further
parameter will also be date.
I use FB 1.5 RC7
cu
Helmut