Re: Error -1235 (misleading message)----here's the code

Well, I realize I was rambling a bit, and I did review the Informix manual, which stated something like popquote() fills in your string with 'len' (the 2nd argument number of bytes), including the null terminator. It apparently doesn't know what to do if you are only interested in one character. I was not using it as a string although I did declare my variable to be long enough to hold the null terminator....my referencing it as *f_ptr_to_char, doesn't care about a null terminator either. My complaint was that the error message states that in an ESQL/C program, I have FETCH'ed something into a variable which is too small, and that in a 4GL program, you should contact Informix. Well, apparently the error was in the '.ec', but of course it is not stopped until it returns to 4GL. Since I didn't have any FETCH statements anywhere, it seemed to be a 4GL problem. You suggested that I send the C & 4GL program to you to find where I was destroying memory, THANKS, but I am now convinced I am handling all my pointers correctly. What I am NOT convinced of is that I am using the poorly documented 4GL routines properly, although from reading the manual, I believe I am. Anyway, here's the code, and it's output: (please advise as to what I am doing wrong) dev:/home/dannyw> cat fgl.4gl {******************************************************************************* *******************************************************************************} MAIN DEFINE f_tote_time FLOAT WHENEVER ANY ERROR STOP DISPLAY "BEFORE" CALL get_hndl_time_4gl( ) RETURNING f_tote_time DISPLAY "AFTER", f_tote_time END MAIN dev:/home/dannyw> cat ec1.ec /******************************************************************************* get_hndl_time_4gl - set up handling time array and return total tote time *******************************************************************************/ int get_hndl_time_4gl( int f_argc ) { if (f_argc) return(0); /*** This should cause a complaint about not returning proper number of values ***/ printf("HERE\\n"); /*** retquote( "0.023" ); THIS WORKS ***/ retflo( 0.023 ); /*** THIS core dumps ***/ printf("THERE\\n"); return(1); /* ZZZ */ } /*************************************************************************** * END OF SOURCE ***************************************************************************/ dev:/home/dannyw> c4gl ec1.ec fgl.4gl ec1.c: fgl.c: dev:/home/dannyw> ./a.out BEFORE HERE Segmentation fault(coredump) dev:/home/dannyw> Interestingly enough, only floating point retxxx() functions (retdub() and retflo()) seem to fail. As is alluded to in the source, retquote() provides the desired result. If it looks right to you, try it on your machine and tell me if it runs....Thanks David Williams wrote: > In article <2E6586C13341E60D.DF49B756DA06A631.F9B3D91E02C0C761@library- > proxy.airnews.net>, Daniel Wright <dw420@airmail.net> writes > >Well, this is one of those misleading error messages I suppose.... > > > >My program is written in 4GL and ESQL/C and this is probably totally > >unrelated to why it started core-dumping (I must be doing something > >wrong), but it consistently core-dumps when I call retflo() with a value > >other than zero....no matter if it is hard-coded, cast to a float or > >whatever.....but I'm still debugging that. This message is about the > >misleading error message I got. > > > >After adding "WHENEVER ANY ERROR STOP" to the code, I got the following > >output (even after I reduced it to a minimum amount of code, with no > >database references and no pointer references). > > > >dev/home/dannyw/dsc1/inv/ictl> ./a.out > >Program stopped at "fu_4gl.4gl", line number 8. > >FORMS statement error number -1235. > >Character host variable is too short for the data. > >dev/home/dannyw/dsc1/inv/ictl> finderr 1235 > >-1235 Character host variable is too short for the data. > > > You've tried to put something into a varable and the variable > is too small. > > >In an ESQL/C program, the program has attempted to fetch a column value > >into a host variable that is not large enough. Use the DESCRIBE command > >to find out the sizes of column values. > > > >If this error arises in a 4GL program, please note all circumstances, > >and contact the Informix Technical Support Department. > > > >Since I naively believed Informix's explanation and wasn't doing any > >FETCH in my EC module, I presumed the 4GL code had caused the problem. > >I was all ready to call Informix Tech Support, when I noticed that if I > >commented out the popquote() function in my EC, the error went away. > > > >I didn't particularly care about how my ptr-to-char was popped off the > >stack (with a null-terminator or not) since I only intended to look at > >the initial character anyway [if (*f_ptr_to_string == 'T') .... else > >.....]. > > > >Incidentally f_ptr_to_string was declared as char f_ptr_to_string[2]; > > > >I decided to review the manual and change the popquote( f_ptr_to_string, > >1); to popquote( f_ptr_to_string, 2 ); > > > Remember C needs the additional null terminator. > > 4GL > DEFINE c CHAR(1) > > C > char c[2]; /* Include null terminator*/ > > >Wow, it worked....[except I still core dump, which I guess is a separate > >problem]. > > > >I'm tired of bitching about stupid problems with 4GL which Informix > >doesn't care to correct...they've already expressed their disinterest in > >maintaining and improving this product, so for what it's worth, don't > >believe your error messages. > > > It's not an Informix problem, your code is wrong.. > > >The only thing I can imagine is causing my program to core-dump on a > >retflo() call is that I must be inadvertently assigning something to a > >pointer which I set incorrectly and am thus wiping out the memory where > >this function resides. > > Well you are trashing memory. Remember in which order you return > arguments to Informix ( try c4gl -keep and look at the .ec file > or check the manals). > > Also don't forget if you are returning 4 arguments you C code > should do a > > ... > return(4); > } > > > > >If you can think of another possibility please let me know.....If it > >matters, this is on HP-UX 10.20 w/ Informix 7.21.UC1 w/ 4GL 6.04.UC3. I > >also got the same -1235 error on an AIX something or other running > >Informix 5.something or other.....didn't follow thru to see if the > Then it's your code. > > try compiling with -g and do > > sdb a.out core > $t > $c > > to get a strack trace and then you can tell where the code dump is > happening. > > >entire program gave me the same core dump...too much trouble to port the > >database and such, when I think the fault must lie with the C > >code....even though myself and a couple of others h