[freetds] odbc on 64 bit machines...

Frediano Ziglio freddyz77 at tin.it
Sat Sep 9 06:29:30 EDT 2006


Il giorno gio, 24/08/2006 alle 10.59 -0400, Christos Zoulas ha scritto:
> Produces the following warnings:
> 
> odbc.c: In function `SQLParamOptions':
> odbc.c:714: warning: cast to pointer from integer of different size
> odbc.c: In function `SQLSetEnvAttr':
> odbc.c:857: warning: cast from pointer to integer of different size
> odbc.c:865: warning: cast from pointer to integer of different size
> odbc.c:869: warning: cast from pointer to integer of different size
> odbc.c: In function `_SQLSetConnectAttr':
> odbc.c:5208: warning: cast from pointer to integer of different size
> odbc.c:5255: warning: cast to pointer from integer of different size
> odbc.c: In function `SQLSetConnectOption':
> odbc.c:5300: warning: cast to pointer from integer of different size
> odbc.c: In function `SQLSetStmtOption':
> odbc.c:5549: warning: cast to pointer from integer of different size
> 

Currently I removed some of then (which was safe), remaining are related
to old functions which shouldn't be used. Note however that SQLLEN is
wrongly 32 bit on suse. The reason is...

> These are caused by the mess on /usr/include/sqltypes.h on my sle-9 box:
> (and SQL{U,}INTEGER being an int instead of a long and used in the
>  odbc code to cast from and to pointers!)
> 
> /*
>  * can't use a long it fails on 64 platforms
>  */
> 
> /*
>  * I (Nick) have made these changes, to cope with the new 3.52 MS
>  * changes for 64 bit ODBC, but looking at MS's spec they havn't
>  * finished it themself. For example, SQLBindCol now expects the
>  * indicator variable to be a SQLLEN which then is a pointer to
>  * a 64 bit value. However the online book that comes with the
>  * headers, then goes on to describe the indicator_ptr in the
>  * descriptor record (which is set by SQLBindCol) as a pointer
>  * to a SQLINTEGER (32 bit). So I don't think its ready for the
>  * big time yet. Thats not to mention all the ODBC apps on 64 bit
>  * platforms that this would break...
>  *
>  * I have just discovered that on win64 sizeof(long) == 4, so its
>  * all smoke and mirrors...
>  *
>  */
> 
> #if (SIZEOF_LONG == 8)
> #ifndef DO_YOU_KNOW_WHAT_YOUR_ARE_DOING

this... if DO_YOU_KNOW_WHAT_YOUR_ARE_DOING is not defined 32 bit is
used... note that this constants should be used for both unixODBC and
FreeTDS (FreeTDS calls odbc_config to get correct defines). 

> typedef int             SQLINTEGER;
> typedef unsigned int    SQLUINTEGER;
> #define SQLLEN          SQLINTEGER
> #define SQLULEN         SQLUINTEGER
> #define SQLSETPOSIROW   SQLUSMALLINT
> typedef SQLULEN         SQLROWCOUNT;
> typedef SQLULEN         SQLROWSETSIZE;
> typedef SQLULEN         SQLTRANSID;
> typedef SQLLEN          SQLROWOFFSET;

Here is 32 bit

> #else
> typedef int             SQLINTEGER;
> typedef unsigned int    SQLUINTEGER;
> typedef long            SQLLEN;
> typedef unsigned long   SQLULEN;

Here is 64 bit (if long is 64 bit)

> typedef unsigned long   SQLSETPOSIROW;
> /*
>  * These are not supprted on 64bit ODBC according to MS
>  * typedef SQLULEN SQLTRANSID;
>  */
> typedef SQLULEN SQLROWCOUNT;
> typedef SQLUINTEGER SQLROWSETSIZE;
> typedef SQLLEN SQLROWOFFSET;
> #endif
> #else
> typedef long            SQLINTEGER;
> typedef unsigned long   SQLUINTEGER;
> #define SQLLEN          SQLINTEGER
> #define SQLULEN         SQLUINTEGER
> #define SQLSETPOSIROW   SQLUSMALLINT
> typedef SQLULEN         SQLROWCOUNT;
> typedef SQLULEN         SQLROWSETSIZE;
> typedef SQLULEN         SQLTRANSID;
> typedef SQLLEN          SQLROWOFFSET;
> #endif
> 
> 
> So what to do here?
> 
> christos

I think the better think to do would be to disable some setting for
functions that are not 64 bit safe. For instance SQLSetConnectOption
should not be called if fOption require vParam to be converted to a
pointer. In this case if SQLULEN is 32 bit we cannot convert is safely
to a pointer. Note that when SQLSetConnectOption was introduced fOption
couldn't specify a pointer so it shouldn't be a problem for ODBC
compliant applications.

freddy77





More information about the FreeTDS mailing list