Re: UDR returns int8
scott's C UDR returning int8 (ifx_int8_t*) gave 1208331480 instead of a value. Donny suggested mi_dalloc with PER_STMT_EXEC, or mi_switch_mem_duration, since mi_zalloc defaults to PER_ROUTINE; it made no difference. Donny noted the number looks like a memory address and, testing himself, saw the same output only when the function was registered as returning int rather than int8, and asked scott to check. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
scott wrote: > I'm trying to write a UDR in C. I can't get any reasonable numbers > back. > > If I've read things right, this should return null: > > ifx_int8_t* bogus(ifx_int8_t* dummy) > { > ifx_int8_t* rvalue=mi_zalloc(sizeof(ifx_int8_t)); > return rvalue; > } > The default memory duration for mi_zalloc is PER_ROUTINE, which means that rvalue will go out of scope (be freed) by IDS at the end of the UDR. Try mi_dalloc() with PER_STMT_EXEC followed by a memset. Alternatively use mi_switch_mem_duration() before the mi_zalloc() call. Cheers, Donny
Thanks, Donny! That makes a great deal of sense. Unfortunately (for me) it doesn't seem to make a difference. This returned 1208331480 rather than null. #include <milib.h> ifx_int8_t* bitand_i8(ifx_int8_t* arg1, ifx_int8_t* arg2) { ifx_int8_t* result=mi_dalloc(sizeof(ifx_int8_t),PER_STMT_EXEC); memset(result,0,sizeof(ifx_int8_t)); return result; } The IBM Informix Datablade API Programmer's Guide tells me to use PER_ROUTINE duration: http://publibfp.boulder.ibm.com/epubs/pdf/ct1t7na.pdf on page 12-18. Cheers! scott
scott wrote: > Thanks, Donny! > > That makes a great deal of sense. Unfortunately (for me) it doesn't > seem to make a difference. This returned 1208331480 rather than null. > May I ask how you are inspecting the value? Are you using some "ifx" version of scanf()? Obviously a "%d" format to one of the printf variants will just give you the address of the structure! (And 1208331480 is 0x4805acd8 in hex, which looks like a memory address to me.) Donny
My DBA registers the function with Informix (it's built as a .so shared
object) and we call it from dbaccess:
execute function bitand_i8(123,123)
It's looking to me like the value we're getting back is an address, and
that ifx isn't doing the right indirection to get to the actual value.
The alignment of the address changes as we add things to the UDR
function's stack, and remove them.
I hesitate to point fingers, but this is what I'm going to tell tech
support. Cross your fingers for me.
Thanks!
scott
scott wrote:
> My DBA registers the function with Informix (it's built as a .so shared
> object) and we call it from dbaccess:
>
> execute function bitand_i8(123,123)>
> It's looking to me like the value we're getting back is an address, and
> that ifx isn't doing the right indirection to get to the actual value.
> The alignment of the address changes as we add things to the UDR
> function's stack, and remove them.
>
> I hesitate to point fingers, but this is what I'm going to tell tech
> support. Cross your fingers for me.
>
> Thanks!
> scott
>
Thought I'd give this a go myself. I used this C code:
ifx_int8_t* bogus()
{
ifx_int8_t* rvalue=mi_zalloc(sizeof(ifx_int8_t));
return rvalue;
}
I got the following from dbaccess when I registered the function like this:
create function bogus () returns int8 external name "<blah>" language c;
#################### dbaccess output start ####################
> execute function bogus();
(expression)
1 row(s) retrieved.
>
#################### dbaccess output end ######################
I got the following from dbaccess when I registered the function like this:
create function bogus () returns int external name "<blah>" language c;
#################### dbaccess output start ####################
> execute function bogus();
(expression)
1156204168
1 row(s) retrieved.
>
#################### dbaccess output end ######################
Are you sure you are returning and int8 and not an int?
Donny