Re: Informix/4GL REALLY SUCKS

On Fri, 19 Dec 1997, Daniel Wright wrote: > 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 reference and not the value but > retflo()? I do not know why this is the case. I am almost certain that the reason is lost in the mists of time -- it is because of Ancient History. If forced to guess, I would say it was related to the days when I4GL had to be ported to hardware without floating point arithmetic (8086, 80286 -- remember them?), which was also the days before it was automatic that C compilers could pass structures by value (you did know that you were not able to pass structures by value in the original K&R C book, didn't you?). Anyway, in those long gone days, Informix would compile I4GL on some machines using DECIMAL(8) in lieu of C float and DECIMAL(16) in lieu of C double. Since a DECIMAL is a data structure, if the functions were to work with float/double and dec_t, the value had to be passed by reference. > 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? But it does. Look in fglusr.h, which is in $INFORMIXDIR/incl/tools. I put that header there for exactly that sort of reason. It probably requires __STDC__ to be defined by your compiler, and it certainly has to be used to do you any good, but it was added in (I think) 4.13/6.01. > [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. I agree! > as if I really want to know why 4GL can't use standard argument passing.] I4GL can't use regular C argument passing because it does type conversions on popped values as required. You pass a FLOAT into a function and pop it into a VARCHAR, or CHAR, without running into problems. Also, it has to care about SQL NULL values -- hate them, hate them, hate them! > 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? I am reasonably confident that the manual does show retflo() and retdub() taking pointers. You'd have to check in Chapter 2 of one of the manuals; I think its the reference manual. I'm packed up for an office move so I can't look at mine. > 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? Yes. > Tell me why this is not an inconsistency in the 4GL toolset! It is an inconsistency, but changing it would break compatability. It has been as it is since release 1.00.00A. It could be addressed by adding two new functions: void retfloat(double d); void retdouble(double d); Why do both take double arguments? Because theoretically, some compilers don't take prototypes still -- I think the standard HP-UX C compiler distributed with the base o/s (used for relinking the kernel and that's all) doesn't. But, anyway, traditionally, I4GL has been compiled without prototypes and therefore the hypothetical retfloat() function cannot be guaranteed to have a prototype in scope, so taking a double is the only completely safe mechanism. I'd be willing to entertain an alternative theory: all modern serious development compilers now handle prototypes. In that case, the retfloat() function could be prototyped with a float argument. At the same time, I'd fix the headers fglsys.h and fglusr.h so that only the prototype function declarations were visible. Since no old code would use these functions, no old code could be broken by adding them. Unfortunately, I'm not in charge of such issues, much as I'd like to get things like this fixed. > 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. No; only reading the documentation will cure this problem, I regret to say. > 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. Be careful: you can't use the following because the string is always null terminated in the available space, so the code will always satisfy the assertion: char c; popquote(&c, sizeof(c)); assert(c == '\\0'); Yours, Jonathan Leffler (johnl@informix.com) #include <witticism.h>