Problem with high OIDs because of changed atol behaviour

Hello,

we ran into a problem because a Windows 32 bit application is looking for=
rows within the tables of pg_catalog via OID - using psqlODBC (32 bit).
As OIDs are unsigned they can be of higher value than INT_MAX. However, O=
IDs greater than INT_MAX seem to be getting clamped to INT_MAX:
http://archives.postgresql.org/pgsql-admin/2011-01/msg00003. php

The problem still persists in psqlodbc 09.00.0200.

We had a look at the sources of v08.04.0200 to get a clue:

convert.c:

/*
* Macros for unsigned long handling.
*/
#ifdef WIN32
#define ATOI32U atol
#elif defined(HAVE_STRTOUL)
#define ATOI32U(val) strtoul(val, NULL, 10)
#else /* HAVE_STRTOUL */
#define ATOI32U atol
#endif /* WIN32 */


/*
* Macros for BIGINT handling.
*/
#ifdef ODBCINT64
#ifdef WIN32
#define ATOI64 _atoi64
#define ATOI64U _atoi64
#define FORMATI64 "%I64d"
#define FORMATI64U "%I64u"
#elif (SIZEOF_LONG == 8)
â€=A6

It seems that as of Microsoft Visual C++ 2005 values exceeding the positi=
ve integer limit let atol return LONG_MAX and values exceeding the negati=
ve integer limit let atol return LONG_MIN.
In case of these overflows errno is set to ERANGE. If the parameter that =
has been passed is NULL, the invalid parameter handler is being invoked -=
as described in parameter validation.
If resuming of execution is allowed these functions set errno to EINVAL a=
nd return 0.

In Microsoft Visual C++ 2003 (and earlier versions) there was no such err=
or handling of these overflows.

We suggest some changes within convert.c that might solve this problem:

/*
* Macros for unsigned long handling.
*/
#ifdef WIN32
#define ATOI32U(val) strtoul(val, NULL, 10)
#elif defined(HAVE_STRTOUL)
#define ATOI32U(val) strtoul(val, NULL, 10)
#else /* HAVE_STRTOUL */
#define ATOI32U atol
#endif /* WIN32 */


/*
* Macros for BIGINT handling.
*/
#ifdef ODBCINT64
#ifdef WIN32
#define ATOI64(val) _strtoi64(val, NULL, 10)
#define ATOI64U(val) _strtoui64(val, NULL, 10)
#define FORMATI64 "%I64d"
#define FORMATI64U "%I64u"
#elif (SIZEOF_LONG == 8)
â€=A6

Could look into this, please?

Thank you very much,

Peter
--=20
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! =20
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Problem with high OIDs because of changed atol behaviour

Hi,

(2011/01/15 0:00), Jan-Peter Seifert wrote:
> Hello,
>
> we ran into a problem because a Windows 32 bit application is looking f=
or rows within the tables of pg_catalog via OID - using psqlODBC (32 bit)=
..
> As OIDs are unsigned they can be of higher value than INT_MAX. However,=
OIDs greater than INT_MAX seem to be getting clamped to INT_MAX:
> http://archives.postgresql.org/pgsql-admin/2011-01/msg00003. php
>
> The problem still persists in psqlodbc 09.00.0200.
>
> We had a look at the sources of v08.04.0200 to get a clue:
>
> convert.c:
>
> /*
> * Macros for unsigned long handling.
> */
> #ifdef WIN32
> #define ATOI32U atol
> #elif defined(HAVE_STRTOUL)
> #define ATOI32U(val) strtoul(val, NULL, 10)
> #else /* HAVE_STRTOUL */
> #define ATOI32U atol
> #endif /* WIN32 */
>
>
> /*
> * Macros for BIGINT handling.
> */
> #ifdef ODBCINT64
> #ifdef WIN32
> #define ATOI64 _atoi64
> #define ATOI64U _atoi64
> #define FORMATI64 "%I64d"
> #define FORMATI64U "%I64u"
> #elif (SIZEOF_LONG == 8)
> â€=A6
>
> It seems that as of Microsoft Visual C++ 2005 values exceeding the posi=
tive integer limit let atol return LONG_MAX and values exceeding the nega=
tive integer limit let atol return LONG_MIN.
> In case of these overflows errno is set to ERANGE. If the parameter tha=
t has been passed is NULL, the invalid parameter handler is being invoked=
- as described in parameter validation.
> If resuming of execution is allowed these functions set errno to EINVAL=
and return 0.
>
> In Microsoft Visual C++ 2003 (and earlier versions) there was no such e=
rror handling of these overflows.
>
> We suggest some changes within convert.c that might solve this problem:
>
> /*
> * Macros for unsigned long handling.
> */
> #ifdef WIN32
> #define ATOI32U(val) strtoul(val, NULL, 10)
> #elif defined(HAVE_STRTOUL)
> #define ATOI32U(val) strtoul(val, NULL, 10)
> #else /* HAVE_STRTOUL */
> #define ATOI32U atol
> #endif /* WIN32 */
>
>
> /*
> * Macros for BIGINT handling.
> */
> #ifdef ODBCINT64
> #ifdef WIN32
> #define ATOI64(val) _strtoi64(val, NULL, 10)
> #define ATOI64U(val) _strtoui64(val, NULL, 10)
> #define FORMATI64 "%I64d"
> #define FORMATI64U "%I64u"
> #elif (SIZEOF_LONG == 8)
> â€=A6
>
> Could look into this, please?

Thanks for your investigation.
I would take of it.

regards,
Hiroshi Inoue

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Problem with high OIDs because of changed atol behaviour

Hello Inoue-san,

sorry for asking again.

So will there be an official patch for this problem?

Could you tell me, please?

Thank you very much in advance,

Peter

-------- Original-Nachricht --------
> Datum: Sun, 16 Jan 2011 19:18:19 +0900
> Von: Hiroshi Inoue
> An: Jan-Peter Seifert
> CC: pgsql-odbc@postgresql.org
> Betreff: Re: [ODBC] Problem with high OIDs because of changed atol beha=
viour

> Hi,
>=20
> (2011/01/15 0:00), Jan-Peter Seifert wrote:
> > Hello,
> >
> > we ran into a problem because a Windows 32 bit application is looking
> for rows within the tables of pg_catalog via OID - using psqlODBC (32 b=
it).
> > As OIDs are unsigned they can be of higher value than INT_MAX. Howeve=
r,
> OIDs greater than INT_MAX seem to be getting clamped to INT_MAX:
> > http://archives.postgresql.org/pgsql-admin/2011-01/msg00003. php
> >
> > The problem still persists in psqlodbc 09.00.0200.
> >
> > We had a look at the sources of v08.04.0200 to get a clue:
> >
> > convert.c:
> >
> > /*
> > * Macros for unsigned long handling.
> > */
> > #ifdef WIN32
> > #define ATOI32U atol
> > #elif defined(HAVE_STRTOUL)
> > #define ATOI32U(val) strtoul(val, NULL, 10)
> > #else /* HAVE_STRTOUL */
> > #define ATOI32U atol
> > #endif /* WIN32 */
> >
> >
> > /*
> > * Macros for BIGINT handling.
> > */
> > #ifdef ODBCINT64
> > #ifdef WIN32
> > #define ATOI64 _atoi64
> > #define ATOI64U _atoi64
> > #define FORMATI64 "%I64d"
> > #define FORMATI64U "%I64u"
> > #elif (SIZEOF_LONG == 8)
> > â€=A6
> >
> > It seems that as of Microsoft Visual C++ 2005 values exceeding the
> positive integer limit let atol return LONG_MAX and values exceeding th=
e
> negative integer limit let atol return LONG_MIN.
> > In case of these overflows errno is set to ERANGE. If the parameter t=
hat
> has been passed is NULL, the invalid parameter handler is being invoked=
-
> as described in parameter validation.
> > If resuming of execution is allowed these functions set errno to EINV=
AL
> and return 0.
> >
> > In Microsoft Visual C++ 2003 (and earlier versions) there was no such
> error handling of these overflows.
> >
> > We suggest some changes within convert.c that might solve this proble=
m:
> >
> > /*
> > * Macros for unsigned long handling.
> > */
> > #ifdef WIN32
> > #define ATOI32U(val) strtoul(val, NULL, 10)
> > #elif defined(HAVE_STRTOUL)
> > #define ATOI32U(val) strtoul(val, NULL, 10)
> > #else /* HAVE_STRTOUL */
> > #define ATOI32U atol
> > #endif /* WIN32 */
> >
> >
> > /*
> > * Macros for BIGINT handling.
> > */
> > #ifdef ODBCINT64
> > #ifdef WIN32
> > #define ATOI64(val) _strtoi64(val, NULL, 10)
> > #define ATOI64U(val) _strtoui64(val, NULL, 10)
> > #define FORMATI64 "%I64d"
> > #define FORMATI64U "%I64u"
> > #elif (SIZEOF_LONG == 8)
> > â€=A6
> >
> > Could look into this, please?
>=20
> Thanks for your investigation.
> I would take of it.
>=20
> regards,
> Hiroshi Inoue

--=20
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! =20
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc