[unixODBC-dev] SQL_C integer sizes in 64-bit Linux

Eric Sharkey sharkey at netrics.com
Wed Mar 2 19:52:26 GMT 2005

> The reason I ask is that in the PostgreSQL driver, SQL_C_SLONG maps to a 
> long, which on x86-64/gcc is a 64-bit integer.  That leaves no SQL_C 
> constant mapping to a 32-bit integer on this platform.
> It seems to me the better binding would be SQL_C_SLONG/int4 and 

I would agree with you.

The datatypes are defined here:


But the "C type" column in that table is a bit Microsoft-centric.
A long int is 32 bits in Microsoft compilers, even on the 64-bit
Windows platforms.  I think what they mean is that the types listed
in that table are the types for Microsoft compilers and that other
compilers may implement them under different names.  They have a
comment to that effect for the BIGINT types (that a type named
_int64 may not be provided by non-MS compilers) and I think
they're just being sloppy by not spelling that out more clearly.

If the PostgreSQL driver has taken this table literally, then
I think that's something you need to bring up with the authors of that
driver, but I don't you're correct here.  As far as I can tell,
in the PostgreSQL driver, SQL_C_SLONG maps to a 4 byte int.

For example, see this in convert.c:

      case SQL_C_SLONG:
      case SQL_C_LONG:
              len = 4;
              if (bind_size > 0)
                      *((SDWORD *) rgbValueBindRow) = atol(neut_str);
                      *((SDWORD *) rgbValue + bind_row) = atol(neut_str);

An SDWORD isn't always a long:

#if (SIZEOF_LONG == 4)
typedef long int                SDWORD;
typedef unsigned long int       UDWORD;
typedef int                     SDWORD;
typedef unsigned int            UDWORD;


More information about the unixODBC-dev mailing list