Re: Informix/4GL REALLY SUCKS

Gee....my copy of K&R (vol. I) doesn't really allude to floats or doubles being anything other than standard data types. Also, strings are a special case in C, they are not a standard data type (refer to page 33-34 of original K&R "There are only a few basic data types in C.....char...int...float...double...") . An array of characters is an array of a data type....the fact that C recognizes that strings are null terminated is somewhat different than other arrays of data types, thus making it a special case. If 'floatives' have to be implemented as pointers as some have suggested, this is a lower level issue, which I shouldn't have to mess with in C (That's why we're not doing assembly!). David Williams wrote: > In article <5F8A271D267F79CE.0A12CBF42A453779.E4C4CCCD8A04AE60@library- > proxy.airnews.net>, Daniel Wright <dw420@airmail.net> writes > >Well, if you've been following this thread like I have (and maybe David Williams > >is > >the only one to give a half-assed reading to my post...yes it was half-assed > >David!), then you'll be very interested to know that for some strange reason, > >Informix appears to have written the retflo() function, and presumably the > >retdub() > >function completely inconsistently with all their other retxxx() functions. > > > >I am very eager to get to work tomorrow and actually check the docs, but it > >appears > >that while retint() and retlong() accept 'pass-by-value', retflo() demands pass > >by > >reference. WHY? I cannot fathom why...If anyone has an explanation, I'd love > >to > >hear it. Obviously retquote() is a special case which would demand the > > Because char strings are a standard C datatype. Integers (and hence > serials and dates) and smalls are standard C data types. They come with > the language. Floative are structs (as are decimals). > > Internally Informix can do *int = *int i.e. take your pointer and > transfer it in one op. With structs it is either a byte copy or element > by element copy. I suspect they though passing by was easier?. No I'm > not conviency either. > > >reference > >and not the value but retflo()? > > > >Okay, even if there is a reasonable explanation for pass-by-reference for > >retflo(), > >why the hell!!!! doesn't Informix provide a function prototype (as in a header > >file) > >so the compiler will warn me when I pass it a float instead of a pointer to a > >float? > > > >[If the documentation is really correct and I just missed this, PLEASE don't > >ignore > >the question as to the lack of a header file! Header files are a VERY important > >part of the C language and are intended to allow people to know how to use > >functions > >without the need to know what goes on in the internal workings of those > >functions....as if I really want to know why 4GL can't use standard argument > >passing.] > > > >Also, if there really is a need to be inconsistent, a more obvious notation in > >the > >docs would be in order!!! If indeed, the manual correctly showed that retflo() > >wanted a pointer and not a value, I certainly missed it....and it's not > >surprising....again, why would you need anything than a standard C data value? > > > >C'mon, Informix....people still do use 4GL, although we are rapidly moving away > >from > >it and in fact rapidly moving away from dependence on any one specific database > >engine....Despite market considerations, you're total abandonment of 4GL as a > >development tool is another major reason.....Are you listening Leffler? Tell me > >why > >this is not an inconsistency in the 4GL toolset! This is one example, where you > >can't say we can solve all our problems by upgrading....and then telling us the > >next > >release won't be available for another 3 months. > > > > > > > >Daniel Wright wrote: > > > >> 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