From: | "Adam M" <gnuman1(at)gmail(dot)com> |
---|---|
To: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: Compiler warnings in psqloodbc 08.03.0200 |
Date: | 2008-10-03 22:00:11 |
Message-ID: | 84b37b360810031500q184f1c91g24d1f276fee8ff56@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Marcin Ligorowski | 2008-10-09 13:08:36 | Soalris compiller error for driver 08.03.0300 |
Previous Message | Hiroshi Saito | 2008-10-03 14:42:36 | Re: Compiler warnings in psqloodbc 08.03.0200 |