Re: Informix/4GL REALLY SUCKS

On Mon, 22 Dec 1997, Daniel Wright wrote: } Gee....my copy of K&R (vol. I) I mentioned K&R; I don't think David Williams did. } doesn't really allude to floats or doubles being anything other than } standard data types. Nor does mine. And I didn't say that it did. I did observe that on some machines, Informix software was compiled to use the dec_t structure instead of float and double, because those machines did not have hardware support for float and double (which meant that the C compiler provided a software package to do float and double calculations). I also observed that at the time K&R was originally written, it was not possible to pass structures by value. Some C compilers allowed you to write code that looked as if structures were being passed by value but the code generated implicitly passed a pointer; also, the receiving functions could be written to look as if they received a structure by value but they interpreted it as if they got a pointer to the data in the assembly code (translating references to structure members written as value.member as if it was written value->member). Be thankful that we no longer have to worry about such vagaries! Since dec_t is a structure, and since the objective would be to allow either a dec_t or a double to be passed without changing the source code, the parameter type would have to be a pointer, not a value (because if dec_t was being used to pass the value, it would have to be passed as a pointer). I also commented that I didn't know that this was the case -- I was speculating. } 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!). Agreed. But, I am documenting a possible historical (hysterical) reason for the odd interface to the float and double interfaces. My manuals got delivered to the wrong building, so I still can't verify what the 6.0 manuals say. I will, however, forward your observations on the misprint to the doc@informix.com alias, as you, and anybody else who finds a problem in the Informix manuals, is encouraged to do by the blurb in the manuals. } 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