mariuz
2012-02-14 14:06:37 UTC
I have seen this bug on the gmane results for firebird
I don't know if is fixed already in the driver
https://bugs.freedesktop.org/show_bug.cgi?id=45881
The driver uses the C/C++ dataype "long" for the SQL datatype "Integer" and for ODBC C type identifier SQL_C_SLONG. It should use the ODBC
C typedef of SQLINTEGER for that, which depending on platforms will be "int" or "long" or even (theoretically) something else.
Integer / SQL_INTEGER / SQL_C_SLONG / SQLINTEGER is a 32 bit integer.
On Windows (32 bit or 64 bit), long == int == 32 bit integer, so one can use "long" or "int" interchangeably and the bug does not appear.
On most modern 32 bit Unices, long == int == 32 bit integer, so again the bug does not appear.
On most modern 64 bit Unices, int == 32 bit integer and long == 64 bit integer, so not the same one => need to use the right one.
I don't know if is fixed already in the driver
https://bugs.freedesktop.org/show_bug.cgi?id=45881
The driver uses the C/C++ dataype "long" for the SQL datatype "Integer" and for ODBC C type identifier SQL_C_SLONG. It should use the ODBC
C typedef of SQLINTEGER for that, which depending on platforms will be "int" or "long" or even (theoretically) something else.
Integer / SQL_INTEGER / SQL_C_SLONG / SQLINTEGER is a 32 bit integer.
On Windows (32 bit or 64 bit), long == int == 32 bit integer, so one can use "long" or "int" interchangeably and the bug does not appear.
On most modern 32 bit Unices, long == int == 32 bit integer, so again the bug does not appear.
On most modern 64 bit Unices, int == 32 bit integer and long == 64 bit integer, so not the same one => need to use the right one.