Re: C and 4gl

In article <3jko08$kp3@cssun.mathcs.emory.edu> ddx85qr@boots.bell-atl.com (Dave Snyder) writes: >Quoting gbw@netcom.com... >> >> I am writing C functions which are to be called from Informix-4gl and I am >> using popint(), popquote() etc. to retrieve arguments off the 4gl stack. >> >> The problem with this is that you need to know the type of each argument in >> advance in order to know which popXXX() function to call. >> >> In my situation it is not OK to just use popquote() with a sufficiently >> large buffer with the understanding that 4gl can convert almost any type >> into a string. I really do need to know what the types are. >> >First of all, the largest a string comming off the stack can be is 512 >bytes. As for your mail in general... I don't see the problem. If >you are writing a C routine for an existing 4GL program, look at the >4GL code and write your C routine accordingly. If you write a C routine >for someone else to use at a later time, document the routine so that >they can write the 4GL program accordingly. Sorry Dave, I think you missed both points. 1. Strings coming off the stack can be greater that 512. The documented limit is 32767. However in practice only 32766 can be used due to a 4GL bug. I think you were only considering how large a string can be that is returned from a function. 2. I have long lobbied for a documented way to determine the type and length of each argument on the stack as this allows one to write truly general purpose functions. For example I have a dynamic array package for 4gl that allows me to do such things as: CALL farray_put(handle, index, record.*) This routine works no matter what record.* looks like and is extremely efficient. However, my routines take advantage of undocumented mechanisms to determine the arguments. This includes blobs, for which the "pop everything as strings" idea doesn't work. Scott