Frank Schlottmann-Goedde wrote:

>
> Frank Ingermann schrieb:
> > Hi Raymond,
> >
> > Raymond Kennington wrote:
> >
> >>>declare external function f_lrTrim
> >>> cstring(254)
> >>> returns
> >>> cstring(254) /* free_it */
> >>> entry_point 'lrTrim' module_name 'FreeUDFLib.dll';
> >>
> >>Why is /* free_it */ commented out?
>
> Avoid it if possible. You will need ib_util to use it,
> it is much safer to use 'RETURNS PARAMETER X' as FB/IB allocates and
> disposes the necessary memory for you.

This is a deprecated technique. Frank Ingermann quoted the following documentation:

"<quote from doc0593.htm>
3)RETURNS PARAMETER N: Use this argument to the DECLARE EXTERNAL FUNCTION state
ment
that specifies that the return value for the UDF is stored in the input paramet
er N. This feature has
been deprecated and was not certified under 5.x; it was by accident that it was
documented in the manuals."

>
> Very simple example: (Note the declaration as procedure, as the result
> is returned in the third parameter.)
>
> ...
> procedure str_cat(a,b,buf:pchar);cdecl;export;
> begin
> strcopy(buf,a);
> strcat(buf,b);
> end;
>
> ...
>
> exports
> str_cat name 'str_cat';
>
> SQL-Declaration
> /* concatenates the two input strings, null values are
> handled as empty strings */
> DECLARE EXTERNAL FUNCTION str_cat
> cstring(254),cstring(254),cstring(512)
> RETURNS PARAMETER 3
> ENTRY_POINT 'str_cat' MODULE_NAME 'libfpc_udf_str';
>
> and usage:
>
> SELECT
> RDB$SECURITY_CLASS||'test' as test_Returning_Null,
> str_cat(RDB$SECURITY_CLASS,'test') as test_Cat,
> str_cat('Free',' Pascal')
> FROM RDB$DATABASE;
>
> Frank

I used this technique and was instructed to not use it, but to use malloc(). Then I was
instructed to use ib_util_malloc or my UDF will cause InterBase to go boom in the night.

This is driving my crazy.

Is there a definative answer to using strings in UDFs that are thread-safe and not
deprecated?

--
Raymond Kennington
Programming Solutions
W2W Team B