Re: FORMAT_INTEGER is wrong on (some) 64 bit platforms?
От | Matt Lilley |
---|---|
Тема | Re: FORMAT_INTEGER is wrong on (some) 64 bit platforms? |
Дата | |
Msg-id | 51EFE6A6.8080303@securitease.com обсуждение исходный текст |
Ответ на | Re: FORMAT_INTEGER is wrong on (some) 64 bit platforms? ("Inoue, Hiroshi" <inoue@tpf.co.jp>) |
Ответы |
Re: FORMAT_INTEGER is wrong on (some) 64 bit platforms?
|
Список | pgsql-odbc |
On 24/07/13 3:22 PM, Inoue, Hiroshi wrote: > Hi Matt, > > (2013/07/24 3:32), Matt Lilley wrote: >> Hello, >> >> I'm trying to understand the logic in psqlodbc.h where if the size of a >> long int is not 8 that FORMAT_INTEGER is set to "%ld". > > Is the version 9.02.0100? Yes. Tip of master. > Does replacing SIZEOF_LONG_INT by SIZEOF_LONG work? Yes. Then I get the first branch, which has "%d" and "%u". Regards, Matt > > regards, > Hiroshi Inoue > > > I can't find any >> definitive documentation, but I gather from various forum posts that the >> size of SQL_C_LONG is always intended to be 4 bytes, independent of the >> host architecture. (This exact issue was first reported 9 years ago, it >> seems [1]). I don't think it should matter what size long int is on the >> host: surely it should only matter what the type being passed into >> SQLBindParameter is given as, since the data is packed by the caller, >> not the callee. My initial instinct was just to change the macro from >> "%ld" to "%d" (and similarly, "%lu" to "%u" for FORMAT_UINTEGER), but >> since there is quite a bit of code in there trying to make sense of it, >> I thought I'd check here. >> >> FWIW, I got here by trying to bind an integer column to -1 and getting >> an out-of-range error, just like Kelly in [1]. Changing the %ld -> %d >> fixes the symptoms for me. Is there any reason this can't be fixed? >> >> Regards, >> Matt > > -- _____________________________________________ Matt Lilley Software Engineer SecuritEase Tel: +64 4 912-2100 Fax: +64 4 912-2101 E-mail: matt.lilley@securitease.com Web: http://www.securitease.com _____________________________________________ This e-mail has passed our content security scan. It is covered by the confidentiality clauses at http://www.securitease.com/content_and_confidentiality
В списке pgsql-odbc по дате отправления: