Re: Possible poplong bug in 4GL 7.32.FC2 on True64 V5.1 2650 alpha

On Mon, 03 May 2004 02:13:22 -0400, J?rg Spilker wrote: > i changed all the long definitions to int and replaced poplong by popint and > everything is working again (at least on the new platform). But what i don'''t > understand is, that poplong doesn'''t do the necessary conversation. According > to the 4GL/ESQL doc'''s passing parameters in 4GL is not just pushing the > value on the stack but also the datatype. The pop functions then do > conversations. So it should be possible to popqoute an integer value into a > string. Why doesn'''t poplong convert the (32bit) integer from 4GL to C > (64bit) long value automatically? You are correct. Poplong() probably should do the conversion for you. Someone droppped the ball in the .F releases of 4GL. Looks like they just ported the code without making the change to adjust the internal definition of 'long'. Jonathan, can you comment? Art S. Kagel cc: Jonathan Leffler

Art S. Kagel wrote: > On Mon, 03 May 2004 02:13:22 -0400, J?rg Spilker wrote: >>i changed all the long definitions to int and replaced poplong by popint and >>everything is working again (at least on the new platform). But what i donï¿œt >>understand is, that poplong doesnï¿œt do the necessary conversation. According >>to the 4GL/ESQL docï¿œs passing parameters in 4GL is not just pushing the >>value on the stack but also the datatype. The pop functions then do >>conversations. So it should be possible to popqoute an integer value into a >>string. Why doesnï¿œt poplong convert the (32bit) integer from 4GL to C >>(64bit) long value automatically? > > > You are correct. Poplong() probably should do the conversion for you. > Someone droppped the ball in the .F releases of 4GL. Looks like they just > ported the code without making the change to adjust the internal definition > of 'long'. Jonathan, can you comment? How long an essay did you want? Tue64, aka DEC, aka Compaq, aka HP, has a longer history than most bits of 64-bit Informix, and that is actually its downfall. Sorry; I helped with the screw-up back in, oh, 1994 or so, and backwards compatibility does the rest of the damage. I4GL (and IDS, come to that) defines INTEGER type as a 32-bit integer. I4GL originated in the days when 16-bit CPUs were the snazzy new kids on the block, so when it wants to ensure that it is using a 32-bit value, it uses 'long' as the data type. So, the I4GL code generator uses pushlong() to push a 32-bit value, and poplong() to pop a 32-bit value, and retlong() to return a 32-bit value. C compilers on Tru64, not unreasonably, define 'long' as a 64-bit integer. C code written to work correctly on a 32-bit version of I4GL, or a 16-bit version of I4GL, uses long to store INTEGER data, because that's what the c-code version of I4GL does. Said code therefore uses 64-bit variables to store 32-bit values when transferred to a 64-bit compiler. The names like poplong() strongly suggest that the data type should be a long - pity about the reality that it should be int and not long on 64-bit platforms (other than Win64). So, because it seemed likely to give C code the best chance of migrating without needing major rewrites, the DEC Alpha version of I4GL (now called HP Tru64 or thereabouts) still uses long where it should use something else... Other 64-bit platforms got done later, once a semi-opaque type had been defined for 4-byte integers. That's int4 from ifxtypes.h. I believe that on most platforms, the modern interface to, poplong, for example, is: extern void poplong(int4 *p); Except the function actually has a different name and poplong() is a macro defined in fglsys.h. I'm not sure of the details for I4GL 7.3x on Tru64. I think that contains the gist of the issue: * I4GL c-code on DEC Alpha precedes most other 64-bit software. * Minimal source changes seemed to indicate that poplong() et al should accept 64-bit long integers still. * In retrospect, this was probably a mistake. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/