Обсуждение: 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, OIDs greater than INT_MAX seem to be getting clampedto 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) … It seems that as of Microsoft Visual C++ 2005 values exceeding the positive integer limit let atol return LONG_MAX and valuesexceeding the negative 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 handleris 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 error 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) … Could look into this, please? Thank you very much, Peter -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Hi, (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 bit). > As OIDs are unsigned they can be of higher value than INT_MAX. However, OIDs greater than INT_MAX seem to be getting clampedto 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) > … > > It seems that as of Microsoft Visual C++ 2005 values exceeding the positive integer limit let atol return LONG_MAX andvalues exceeding the negative 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 parameterhandler 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 error 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) > … > > Could look into this, please? Thanks for your investigation. I would take of it. regards, Hiroshi Inoue
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 <inoue@tpf.co.jp> > An: Jan-Peter Seifert <Jan-Peter.Seifert@gmx.de> > CC: pgsql-odbc@postgresql.org > Betreff: Re: [ODBC] 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 > 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, > 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) > > … > > > > It seems that as of Microsoft Visual C++ 2005 values exceeding the > positive integer limit let atol return LONG_MAX and values exceeding the > negative 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 > 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 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) > > … > > > > Could look into this, please? > > Thanks for your investigation. > I would take of it. > > regards, > Hiroshi Inoue -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail