Re: Compiler warnings in psqloodbc 08.03.0200 - Mailing list pgsql-odbc
From | Adam M |
---|---|
Subject | Re: Compiler warnings in psqloodbc 08.03.0200 |
Date | |
Msg-id | 84b37b360810031500q184f1c91g24d1f276fee8ff56@mail.gmail.com Whole thread Raw |
In response to | Re: Compiler warnings in psqloodbc 08.03.0200 ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
List | pgsql-odbc |
On Fri, Oct 3, 2008 at 9:42 AM, Hiroshi Saito <z-saito@guitar.ocn.ne.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.
pgsql-odbc by date: