Re: Possible poplong bug in 4GL 7.32.FC2 on True64 V5.1 2650 alpha
Posted in 2004
On Tue, 20 Apr 2004 02:39:42 -0400, J?rg Spilker wrote: > Hello, > > i'''m confused. We recently changed our environment from True64 V4.0 1229 > alpha to V5.1 2650 alpha and also our 4GL developement tools from 7.20.UE3 > to 7.32.FC2 (and also Dynamic server from 7.x to 9.x). > > We'''re using 4GL code calling C Functions. The 4GL Code puts a variable of > type INTEGER on the stack, the C code uses poplong(&l_long) to get it. This > was working with 7.20.UE3. However compiling the code with 7.32.FC2 give > some strange results. Putting an INTEGER value of 1 on the stack gives a > ridiculios high value in l_long. According to the documenation, putting > arguments in 4GL on the stack includes the datatype and the pop functions > can use the type to make any necessary conversions. > > I change all the longs in the C code to int and popint and now it is working > also with 7.32.FC2 (not yet tested if it is working with 7.20.EU3). > > Can anyone explain what happens here? Yes. Your 'C' is treating long as 64bit integers, but likely the 4GL pushlong (implied in the 4GL function call) and the poplong are still pushing and popping 32bits off the stack. Since you are passing the address of the beginning of your 64bit long the 32bit value is being stored in the upper word of the long. Change the datatype in 'C' that is receiving the value from long to int (which is 32bit) and all should be well again. Making longs 64bit on 64bit architectures instead of ints was probably the dumbest thing the ANSI 'C' committee did when it extended the language definition to those platforms. We old school programmers always treated 'int' as a generic machine word sized object to be used ONLY when one does not care or it does not matter the range of values it will hold. We always treated 'long' as it was always defined 'an integer containing at least 32bits'. They were hoping not to break code for 'dumb' programmers so instead they broke code for us smart ones. Go figure! Art S. Kagel