Thread: Odbcapi30.c - 64 bit compiler warning cleanup
<<odbcapi30_64bit.patch>> The attached patch cleans up the 64 bit compiler warnings in odbcapi30.c. Luf, if you're happy, can you add it to your collection of patches ready for application please? I didn't apply it myself in case I break any of yours. Regards, Dave.
Attachment
> The attached patch cleans up the 64 bit compiler warnings in > odbcapi30.c. I'll try it today or tomorrow (I hope). > Luf, if you're happy, can you add it to your collection of patches ready > for application please? I didn't apply it myself in case I break any of > yours. Ok. I apply a lot of them to CVS till end of week. I see no negative reaction - I have to verify the implicit rollback problem. Regards, Luf
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 19 January 2006 11:24 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > > The attached patch cleans up the 64 bit compiler warnings in > > odbcapi30.c. > > I'll try it today or tomorrow (I hope). Thanks - I should add that I'm not sure how to deal with the other ones. I think it needs someone far more experienced in 32/64 bit issues than me to think about it. Regards, Dave.
> > > The attached patch cleans up the 64 bit compiler warnings in > > > odbcapi30.c. > > > > I'll try it today or tomorrow (I hope). I'm a little bit late. I had problems with my 64-bit box during weekend. I have installed pgsql and unixODBC now. I hope I finish this work today. > Thanks - I should add that I'm not sure how to deal with the other ones. > I think it needs someone far more experienced in 32/64 bit issues than > me to think about it. I take a look on it but I think I'm less experienced in C and I have no experience with 32/64 bit issue. Regards, Luf
> I'm a little bit late. I had problems with my 64-bit box during weekend.
> I have installed pgsql and unixODBC now. I hope I finish this work today.
I have problem with auto* tools to create configure :-(
I have x86_64 CentOS 4.2 with all updates. auto* versions:
aclocal (GNU automake) 1.9.2
libtoolize (GNU libtool) 1.5.6
autoconf (GNU Autoconf) 2.59
autoheader (GNU Autoconf) 2.59
automake (GNU automake) 1.9.2
I have installed rpms:
postgresql-8.1.2
postgresql-server
postgresql-libs
postgresql-devel
postgresql-pl
configure.ac:10: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:18: error: possibly undefined macro: AC_CHECK_LIB
configure.ac:19: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:66: error: possibly undefined macro: AC_CHECK_FUNCS
configure.ac:85: error: possibly undefined macro: AC_TRY_COMPILE
Do I need whole postgresql source code? I try give to aclocal rpm build
dir witoccess.
Any ideas?
Luf
-----Original Message-----
From: "Ludek Finstrle"<luf@pzkagis.cz>
Sent: 24/01/06 19:25:45
To: "Dave Page"<dpage@vale-housing.co.uk>
Cc: "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org>
Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup
> Do I need whole postgresql source code?
Yes - see the unix compilation doc for the full steps.
Regards, Dave
-----Unmodified Original Message-----
> I'm a little bit late. I had problems with my 64-bit box during weekend.
> I have installed pgsql and unixODBC now. I hope I finish this work today.
I have problem with auto* tools to create configure :-(
I have x86_64 CentOS 4.2 with all updates. auto* versions:
aclocal (GNU automake) 1.9.2
libtoolize (GNU libtool) 1.5.6
autoconf (GNU Autoconf) 2.59
autoheader (GNU Autoconf) 2.59
automake (GNU automake) 1.9.2
I have installed rpms:
postgresql-8.1.2
postgresql-server
postgresql-libs
postgresql-devel
postgresql-pl
configure.ac:10: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:18: error: possibly undefined macro: AC_CHECK_LIB
configure.ac:19: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:66: error: possibly undefined macro: AC_CHECK_FUNCS
configure.ac:85: error: possibly undefined macro: AC_TRY_COMPILE
Do I need whole postgresql source code? I try give to aclocal rpm build
dir witoccess.
Any ideas?
Luf
> > Do I need whole postgresql source code? > > Yes - see the unix compilation doc for the full steps. I was working with this manual but I maked two mistakes: 1) I didn't copy libtool.m4 2) I used only base pgsql source dir (not config subdir) I have to better read next time. Now I'm able to build it. Thanks, Luf
On 24/1/06 20:39, "Ludek Finstrle" <luf@pzkagis.cz> wrote: >>> Do I need whole postgresql source code? >> >> Yes - see the unix compilation doc for the full steps. > > I was working with this manual but I maked two mistakes: > 1) I didn't copy libtool.m4 > 2) I used only base pgsql source dir (not config subdir) > > I have to better read next time. Now I'm able to build it. I think we've all been there! :-) Regards, Dave.
> The attached patch cleans up the 64 bit compiler warnings in > odbcapi30.c. I test it and add more warning cleanups. I include your patch into attached one. I tried it a little bit on 64-bit and 32-bit box. I don't solve the problem in options.c where 64-bit pointer may be passwd throught 32-bit number. I don't know how to solve it. Please review and comment. Regards, Luf
Attachment
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 26 January 2006 10:18 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > > The attached patch cleans up the 64 bit compiler warnings in > > odbcapi30.c. > > I test it and add more warning cleanups. I include your patch into > attached one. I tried it a little bit on 64-bit and 32-bit box. Compiles without errors or warnings here. > I don't solve the problem in options.c where 64-bit pointer may > be passwd throught 32-bit number. I don't know how to solve it. No nor I. Any chance of a little help with this one please Tom? Regards, Dave.
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> From: Ludek Finstrle [mailto:luf@pzkagis.cz]
>> I don't solve the problem in options.c where 64-bit pointer may
>> be passwd throught 32-bit number. I don't know how to solve it.
> No nor I. Any chance of a little help with this one please Tom?
I assume that you can't alter the signature of PGAPI_SetConnectOption,
ie, vParam really has to be SQLUINTEGER and not some other type?
If so, I'd argue that that whole block (the "if (fOption == 30002 &&
vParam)" stuff) ought to be #ifdef WIN32. It's certainly useless on
any other platform, and Microsoft is never going to figure out how
to 64-bit-ify that pile of junk they call an OS, so no need to bend
our brains wondering how this would work on 64-bit Windows.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 26 January 2006 15:57 > To: Dave Page > Cc: Ludek Finstrle; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > "Dave Page" <dpage@vale-housing.co.uk> writes: > >> From: Ludek Finstrle [mailto:luf@pzkagis.cz] > >> I don't solve the problem in options.c where 64-bit pointer may > >> be passwd throught 32-bit number. I don't know how to solve it. > > > No nor I. Any chance of a little help with this one please Tom? > > I assume that you can't alter the signature of PGAPI_SetConnectOption, > ie, vParam really has to be SQLUINTEGER and not some other type? The spec actually says it should be a SQLPOINTER. Changing to that unleashes a whole barrel of extra fun unfortunately. > If so, I'd argue that that whole block (the "if (fOption == 30002 && > vParam)" stuff) ought to be #ifdef WIN32. It's certainly useless on > any other platform, That's a good point - it didn't even cross my mind that that code is only useful on Windows. Thanks Tom! > and Microsoft is never going to figure out how > to 64-bit-ify that pile of junk they call an OS, so no need to bend > our brains wondering how this would work on 64-bit Windows. There have been 64bit versions of Windows for Itanium for ages, and 2003/XP have also been readily available now for a few months. That said, psqlODBC definitely doesn't support 64 bit builds on Windows yet. Regards, Dave
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page > Sent: 26 January 2006 16:54 > To: Tom Lane > Cc: Ludek Finstrle; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > > > If so, I'd argue that that whole block (the "if (fOption == 30002 && > > vParam)" stuff) ought to be #ifdef WIN32. It's certainly useless on > > any other platform, > > That's a good point - it didn't even cross my mind that that code is > only useful on Windows. Thanks Tom! And the resulting patch is attached, including the other 64 bit changes that Luf & I have made already. Luf, I think it's about time to apply the outstanding fixes and prepare for a release. That OK with you? Regards, Dave.
Attachment
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> That's a good point - it didn't even cross my mind that that code is
>> only useful on Windows. Thanks Tom!
I can confirm that Luf's patch gets rid of all the other 64-bit warnings
for me.
> Luf, I think it's about time to apply the outstanding fixes and prepare
> for a release. That OK with you?
I'm getting antsy to have a release for Fedora 5 ...
regards, tom lane
> > >> I don't solve the problem in options.c where 64-bit pointer may > > >> be passwd throught 32-bit number. I don't know how to solve it. > > > > > No nor I. Any chance of a little help with this one please Tom? > > > > I assume that you can't alter the signature of PGAPI_SetConnectOption, > > ie, vParam really has to be SQLUINTEGER and not some other type? > > The spec actually says it should be a SQLPOINTER. Changing to that > unleashes a whole barrel of extra fun unfortunately. I don't think it will be so problematic. I'll try it. It's the best way to support Win64. Very good point Tom. > > and Microsoft is never going to figure out how > > to 64-bit-ify that pile of junk they call an OS, so no need to bend > > our brains wondering how this would work on 64-bit Windows. > > There have been 64bit versions of Windows for Itanium for ages, and > 2003/XP have also been readily available now for a few months. That > said, psqlODBC definitely doesn't support 64 bit builds on Windows yet. I have no access to 64-bit windows. I have no 64-bit compiler for win :-( We have to hope that someone will donate for 64-bit Windows version or someone with access to 64-bit win with compiler will join us. Regards, Luf
> And the resulting patch is attached, including the other 64 bit changes > that Luf & I have made already. I'm for wait a few days. I want to take a look at PGAPI_SetConnectOption problem again. > Luf, I think it's about time to apply the outstanding fixes and prepare > for a release. That OK with you? Partialy Ok. I need you answer me to: [ODBC] Disallow premature is broken. I apply fixes ASAP (without 64-bit one for PGAPI_SetConnectOption). Regards, Luf
> > > >> I don't solve the problem in options.c where 64-bit pointer may > > > >> be passwd throught 32-bit number. I don't know how to solve it. > > > > > > > No nor I. Any chance of a little help with this one please Tom? > > > > > > I assume that you can't alter the signature of PGAPI_SetConnectOption, > > > ie, vParam really has to be SQLUINTEGER and not some other type? > > > > The spec actually says it should be a SQLPOINTER. Changing to that > > unleashes a whole barrel of extra fun unfortunately. > > I don't think it will be so problematic. I'll try it. It's the best way > to support Win64. Here is my result. Patch attached. I have no 64-bit box ready at hand here. I will test it on 64-bit box tomorrow. Please review and comment Luf
Attachment
> > > The spec actually says it should be a SQLPOINTER. Changing to that > > > unleashes a whole barrel of extra fun unfortunately. > > > > I don't think it will be so problematic. I'll try it. It's the best way > > to support Win64. > > Here is my result. Patch attached. I have no 64-bit box ready at hand here. > I will test it on 64-bit box tomorrow. I find one problem. New patch attached. I get no warning with this one. Please review and comment Luf
Attachment
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 27 January 2006 08:26 > To: Dave Page > Cc: Tom Lane; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > > > > The spec actually says it should be a SQLPOINTER. > Changing to that > > > > unleashes a whole barrel of extra fun unfortunately. > > > > > > I don't think it will be so problematic. I'll try it. > It's the best way > > > to support Win64. > > > > Here is my result. Patch attached. I have no 64-bit box > ready at hand here. > > I will test it on 64-bit box tomorrow. > > I find one problem. New patch attached. I get no warning with > this one. > > Please review and comment Looks good on 64 bit linux and Windows here. BTW, in your version bump commit, you missed a bit in psqlodbc.rc: FILEVERSION 8,1,1,8 PRODUCTVERSION 8,1,1,8 I've committed this, but just in case you weren't aware :-) /D
> > Please review and comment > > Looks good on 64 bit linux and Windows here. > > BTW, in your version bump commit, you missed a bit in psqlodbc.rc: > > FILEVERSION 8,1,1,8 > PRODUCTVERSION 8,1,1,8 My fault. I edit version.h and than I was only looking for '0108' :-( I hope there is no other problem with versioning. > I've committed this, but just in case you weren't aware :-) Thank you a lot Dave. Regards, Luf
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 27 January 2006 09:31 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > > > Please review and comment > > > > Looks good on 64 bit linux and Windows here. > > > > BTW, in your version bump commit, you missed a bit in psqlodbc.rc: > > > > FILEVERSION 8,1,1,8 > > PRODUCTVERSION 8,1,1,8 > > My fault. I edit version.h and than I was only looking for '0108' :-( > I hope there is no other problem with versioning. Not that I spotted! That one stands out though because it's what Windows explorer shows you. > > I've committed this, but just in case you weren't aware :-) > > Thank you a lot Dave. NP. /D
Ludek Finstrle <luf@pzkagis.cz> writes:
> RETCODE SQL_API
> PGAPI_SetConnectOption(HDBC hdbc,
> SQLUSMALLINT fOption,
> ! SQLUINTEGER vParam)
> {
> CSTR func = "PGAPI_SetConnectOption";
> ConnectionClass *conn = (ConnectionClass *) hdbc;
> --- 314,320 ----
> RETCODE SQL_API
> PGAPI_SetConnectOption(HDBC hdbc,
> SQLUSMALLINT fOption,
> ! SQLPOINTER vParam)
> {
> CSTR func = "PGAPI_SetConnectOption";
> ConnectionClass *conn = (ConnectionClass *) hdbc;
The problem with this is that it creates an ABI breakage. I don't think
we can just push this out as a bug fix --- it would require a major
version bump, no?
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 27 January 2006 14:31 > To: Ludek Finstrle > Cc: Dave Page; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > The problem with this is that it creates an ABI breakage. I > don't think > we can just push this out as a bug fix --- it would require a major > version bump, no? Is that actually a problem given that apps should link to the driver manager (which can dynamically load any version of any driver), not directly to the driver itself? Regards, Dave.
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> The problem with this is that it creates an ABI breakage.
> Is that actually a problem given that apps should link to the driver
> manager (which can dynamically load any version of any driver), not
> directly to the driver itself?
Hm, good point. So the question then becomes whether the driver manager
is expecting this parameter to be int-sized or pointer-sized.
I took a quick look at the unixODBC sources (2.0.4 which is what I have
handy, I know it's a bit old) and got completely confused: I see the
parameter declared as SQLUINTEGER in some places and UDWORD in others.
Anyone know that code base well enough to be certain which place is
definitive?
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 27 January 2006 14:45 > To: Dave Page > Cc: Ludek Finstrle; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Odbcapi30.c - 64 bit compiler warning cleanup > > "Dave Page" <dpage@vale-housing.co.uk> writes: > >> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > >> The problem with this is that it creates an ABI breakage. > > > Is that actually a problem given that apps should link to the driver > > manager (which can dynamically load any version of any driver), not > > directly to the driver itself? > > Hm, good point. So the question then becomes whether the > driver manager > is expecting this parameter to be int-sized or pointer-sized. It /should/ be expecting SQLPOINTER (well, SQLSetConnectAttr expects SQLPOINTER, and SQLSetConnectOption maps directly to it according to the spec - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht m/odbcsqlsetconnectattr.asp) > I took a quick look at the unixODBC sources (2.0.4 which is > what I have > handy, I know it's a bit old) and got completely confused: I see the > parameter declared as SQLUINTEGER in some places and UDWORD in others. > Anyone know that code base well enough to be certain which place is > definitive? Not I. Our code seems to be a mess of types as well :-( Regards, Dave.
> > >> The problem with this is that it creates an ABI breakage. > > > > > Is that actually a problem given that apps should link to the driver > > > manager (which can dynamically load any version of any driver), not > > > directly to the driver itself? > > > > Hm, good point. So the question then becomes whether the > > driver manager > > is expecting this parameter to be int-sized or pointer-sized. > > It /should/ be expecting SQLPOINTER (well, SQLSetConnectAttr expects > SQLPOINTER, and SQLSetConnectOption maps directly to it according to the > spec - > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht > m/odbcsqlsetconnectattr.asp) PGAPI_SetConnectOption is private hidden function. It's called from SQL* functions which are public - exported (I'm sorry I'm using terms from OOP but I don't know the right one). No one who follows ODBC specification may use functions which doesn't begin with SQL. The parameter for SQLSetConnectAttr (from which is PGAPI_SetConnectOption mainly called) is SQLPOINTER. I check whole code to calling PGAPI_SetConnectOption so there could be no problem with it. > > I took a quick look at the unixODBC sources (2.0.4 which is > > what I have > > handy, I know it's a bit old) and got completely confused: I see the > > parameter declared as SQLUINTEGER in some places and UDWORD in others. > > Anyone know that code base well enough to be certain which place is > > definitive? > > Not I. Our code seems to be a mess of types as well :-( There is more types in psqlodbc like UInt4, int, ... I think the best API manual is on MS web (Dave's link above). unixODBC follows it. Regards, Luf