Subject | Re: [firebird-support] Re: Need help with FB XOR UDF, please: found fix |
---|---|
Author | Chuck Belanger |
Post date | 2005-06-06T16:23:47Z |
Hi, Leonardo (and anyone else following this):
I finally fixed it this weekend.
This is what I found out:
The procedure or function in Delphi must have "var" in front of Key:
Integer, otherwise when I pass an integer it gets changed to some other
integer entirely. (Why????) Example: I would pass something as simple as
"22" and get a new integer each time I called the procedure for several
times then like I said it would start repeating 2-4 of these integers in
a sequential manner. (Integers like 41004567) (I'm assuming that creating
a strored procedure somehow acts to fix this need for "var" in the call.)
The other thing I observed (thanks for the reminder to have everything go
to a file as I use it to actually see this!) was that XOR gives a 0 when
the two integers compared are the same. Well, this happens pretty
regularly and when this does happen the string passed is then terminated
prematurely when made into a PChar, thus when XOR'd back to the original
string it comes up short.
I fixed this by setting up two vars for NextByte and RandNum and calling
the Ord(P^) and random(254)+1 respectively, then comparing those vars. If
not equal then do the XOR otherwise output either of the vars, NOT 0.
I found this experience very educational about the behaviour of PChars
and FB UDFs.
I really am thankful for the creator of FreeUDFLib in Delphi which made
all this much easier to do by simply adding the new function and not
having to concern myself with memory issues.
Thanks for the help.
Chuck
Leonardo Cosmai wrote:
I finally fixed it this weekend.
This is what I found out:
The procedure or function in Delphi must have "var" in front of Key:
Integer, otherwise when I pass an integer it gets changed to some other
integer entirely. (Why????) Example: I would pass something as simple as
"22" and get a new integer each time I called the procedure for several
times then like I said it would start repeating 2-4 of these integers in
a sequential manner. (Integers like 41004567) (I'm assuming that creating
a strored procedure somehow acts to fix this need for "var" in the call.)
The other thing I observed (thanks for the reminder to have everything go
to a file as I use it to actually see this!) was that XOR gives a 0 when
the two integers compared are the same. Well, this happens pretty
regularly and when this does happen the string passed is then terminated
prematurely when made into a PChar, thus when XOR'd back to the original
string it comes up short.
I fixed this by setting up two vars for NextByte and RandNum and calling
the Ord(P^) and random(254)+1 respectively, then comparing those vars. If
not equal then do the XOR otherwise output either of the vars, NOT 0.
I found this experience very educational about the behaviour of PChars
and FB UDFs.
I really am thankful for the creator of FreeUDFLib in Delphi which made
all this much easier to do by simply adding the new function and not
having to concern myself with memory issues.
Thanks for the help.
Chuck
Leonardo Cosmai wrote:
> ok. the problem is in the sql statement (I don't know why!). If you
> use a store procedure:
>
> CREATE PROCEDURE TEST
> RETURNS (
> V1 Char(100),
> V2 Char(100))
> AS
> DECLARE VARIABLE temp CHAR(100);
> BEGIN
>
> FOR SELECT A_FILD_CHAR FROM A_TABLE INTO :v1
> DO BEGIN
> temp = UDF_STR2STR(v1, 20);
> v2 = UDF_STR2STR(temp, 20);
> SUSPEND;
>
> END
>
>
> END;
>
> you will see that v1 = v2.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.6.4 - Release Date: 06/06/2005