Re: UDR returns int8

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