More Weird Behaviour on a DEC ALPHA

Continuing on with this weird behaviour on a DEC machine. Is anyone aware of any problems with a 64 bit DEC machine. ? Specifically, it seems as if we are getting problems with memory allocation. We have a structure containing various datatypes, some of which are INTEGERS, and the data assigned to those integers seems to overwrite the data stored in subsequent fields. We do get warnings during compilation e.g.. cc: Warning: action_history.ec, line 112: In this statement, the referenced type of the pointer value "&p_subscriber_id" is "int", which is not compatible with "long". (ptrmismatch) poplong(&p_subscriber_id); Now I thought that an INFORMIX integer was the equivalent of a 'C' long datatype Is this different on a 64 bit machine. If so is there a way round it. Rekaish

Informix Integer = <platform specific> C data type. Change your code or use #ifdef MYOS #define pop_inf_int poplong #endif #ifdef MYOS2 #define pop_inf_int popint #endif then use pop_inf_int Rekaish Bhardwaj wrote in message <8psumv$53a$1@news.xmission.com>... > >Continuing on with this weird behaviour on a DEC machine. >Is anyone aware of any problems with a 64 bit DEC machine. ? > >Specifically, it seems as if we are getting problems with memory >allocation. We have a structure containing various datatypes, >some of which are INTEGERS, and the data assigned to >those integers seems to overwrite the data stored in subsequent fields. > >We do get warnings during compilation e.g.. > >cc: Warning: action_history.ec, line 112: In this statement, the referenced >type of the pointer value "&p_subscriber_id" is "int", which is not >compatible with "long". (ptrmismatch) >poplong(&p_subscriber_id); > >Now I thought that an INFORMIX integer was the equivalent of a 'C' long >datatype >Is this different on a 64 bit machine. > >If so is there a way round it. > >Rekaish

Rekaish Bhardwaj wrote: > Continuing on with this weird behaviour on a DEC machine. > Is anyone aware of any problems with a 64 bit DEC machine. ? > > Specifically, it seems as if we are getting problems with memory > allocation. We have a structure containing various datatypes, > some of which are INTEGERS, and the data assigned to > those integers seems to overwrite the data stored in subsequent fields. > > We do get warnings during compilation e.g.. > > cc: Warning: action_history.ec, line 112: In this statement, the referenced > type of the pointer value "&p_subscriber_id" is "int", which is not > compatible with "long". (ptrmismatch) > poplong(&p_subscriber_id); > > Now I thought that an INFORMIX integer was the equivalent of a 'C' long > datatype > Is this different on a 64 bit machine. > > If so is there a way round it. With ESQL/C 9.21 (CSDK 2.30), they changed the interface of essentially every ESQL/C function. On a 32-bit machine, the types remained equivalent to the original types, but the new names were things like int2 and int4. On a 64-bit machine, the names stayed the same (int2, int4), but the underlying types sometimes changed (eg instead of being long, it became int4, aka int). Now, you are referring to poplong(); that is, of course, an I4GL function and not an ESQL/C function. If you're using I4GL, the rules are probably different -- I've not verified this -- and it may be that you need to pass a long pointer to the function instead of the int pointer you are passing. The difference could be crucial; one points to 4 bytes of memory and the other to 8 bytes of memory, so you'd get erroneous answers if you pass the wrong sort of pointer. This may have changed on a 64-bit machine with the 7.30 version of I4GL, which uses CSDK 2.30. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v1.00.PC1 -- see http://www.perl.com/CPAN #include <disclaimer.h>