Re: Compiler warnings in psqloodbc 08.03.0200

On Fri, Oct 3, 2008 at 9:42 AM, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> wrote:
> I think that the supplier of unixODBC should have the responsibility. it
> will be clear if expressed
> by "odbc_config --cflags". Then, Is BUILD_REAL_64_BIT_MODE of a definition
> in some
> document? and, How does a user use?
>
> Therefore, I think that supply of the present psqlODBC is the best.

Hiroshi, sorry about the noise - should have sent this to the mailing
list (gmail interface problems :)

While you are correct that unixODBC should be where this is fixed, and
I'll contact the maintainer, psqlODBC should check if a sane ODBC
environment is provided..

What I'm trying to say, is that ODBC, like an application, can be
compiled as a 32-bit application or a 64-bit application. On AMD64

As a 32-bit application, we have sizeof(long) == 4
As a 64-bit application, we have sizeof(long) == 8

Similarly, as an ODBC application, it can be compiled under 32-bit
mode, or a 64-bit mode.

A 32-bit ODBC application, we have sizeof(SQLLEN) == 4
A 64-bit ODBC application, we have sizeof(SQLLEN) == 8

This is exactly what Microsoft is using and AFAIK, they are still the
people that control the ODBC specs,
http://msdn.microsoft.com/en-us/library/ms716287.aspx

Now, unixODBC when compiled as a 64-bit library, can be compiled with
the BUILD_REAL_64_BIT_MODE or without it. Without defining this
constant, the ODBC API supplied by unixODBC is *not* compatible with
64-bit ODBC specs. It is *wrong*.

From the sqltypes.h again, this from from unixODBC developer,

/*
* 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...
*
*/

As you can see, this is not applicable anymore as per the msdn link.
On 64-bit specs SQLLEN is defined to be 64-bit integer, and SQLINTEGER
is defined to be int, which is just 32-bit integer.

I would like to add that testing for broken unixODBC compilations on
64-bit distributions is easy and important at same time. If some
define BUILD_REAL_64_BIT_MODE while others do not, then the
applications that use psqlODBC will not be compatible between
distributions and even not 64-bit clean.

I can add a check to configure.ac to check that sizeof(SQLLEN) is not
sizeof(SQLINTEGER) on 64-bit platforms and post the patch here.

- Adam

PS. I've already been bitten by this bug, kind of indirectly. Qt's
ODBC layer was tested with unixODBC on FreeBSD. They have not defined
BUILD_REAL_64_BIT_MODE so now their ODBC is broken not only on Debian,
but also on Windows 64-bit as they were casting SQLINTEGER into
SQLLEN.. Somehow though, they have not noticed the mistake.
"QODBC plugin code tries to cast a SQLINTEGER pointer to a SQLLEN
pointer" - oops.