Re: Informix/4GL REALLY SUCKS

Well, the documentation was WRONG!!!! Page C-7 of my Informix 4GL Reference Volume Two (Version 6), very clearly shows these as being declared as accepting values, not pointers. By the standards I am held to, this would be a bug since it does not conform to documentation (So maybe the tech. writer is to blame, it's still an Informix problem.) When dealing with version 7 and above, you do make a valid point in that if __STDC__ were defined to be 1, this error would have been caught by the compiler (Version 5 has no header file). I can assure you, it will be defined anytime I compile from now on. Jonathan Leffler wrote: > 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> -- - Danny Wright danwright@bigfoot.com #include <stddisclaimers.h>