Re: Informix/4GL REALLY SUCKS

On Mon, 22 Dec 1997, Daniel Wright wrote: } Well, the documentation was WRONG!!!! OK, it was wrong. I've reported it to the doc alias. I'm sorry it was wrong; I didn't know it was wrong, and neither did anyone else because we would have fixed it before publication if we had known. } 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.) Yes. There is a documentation error. Yes, it is a bug in the Informix documentation. } 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). Assuming by 'Version 5' you mean version 4.1x I4GL, then for x >= 3 (4.13 and later), the header file is provided and has prototypes. If you are using 4.10, 4.11 or 4.12, the header is not provided. } I can assure you, it will be defined anytime I compile from now on. Good. } 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@@NL@