Обсуждение: [BUGS] There is a case in which psqlodbc-09.03.0400 returns unterminated strings on Windows.
Hi, I found a bug which psqlODBC returns a string without null-terminated when SQLFetch is executed on Windows. IMHO, it seems to be caused by differences of snprintf function between Windows and Linux. You have changed sprintf into snprintf at psqlodbc-09.03.0400 release. But snprintf on Windows(_snprintf) doesn't include a terminating character(\0) when a copy buffer length is less than anoriginal buffer length; besides this returns -1. Their behavior are different from that of Linux but psqlODBC does not currently make allowances for their differences. As you can confirm this bug, I attached a program(test.cpp) which reproduces a bug. This result is following. ---- Please Enter key... SQLAllocHandle() OK SQLAllocHandle() ok SQLConnect ok data-length=24 length=-1 //invalid length 2015-09-15 17:48:44.7300ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ・ //unterminated string no data --- To fix this behavior, copy_and_convert_field function and stime2timestamp function need to repair at least. I tried to fix it up and attached a patch on this mail. Could you confirm this? Best Regards --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-anzai@xc.jp.nec.com ---
Вложения
Re: [BUGS] There is a case in which psqlodbc-09.03.0400 returns unterminated strings on Windows.
От
Heikki Linnakangas
Дата:
On 09/16/2015 05:20 AM, Naoya Anzai wrote: > Hi, > > I found a bug which psqlODBC returns a string without null-terminated when SQLFetch is executed on Windows. > IMHO, it seems to be caused by differences of snprintf function between Windows and Linux. > You have changed sprintf into snprintf at psqlodbc-09.03.0400 release. > But snprintf on Windows(_snprintf) doesn't include a terminating character(\0) when a copy buffer length is less than anoriginal buffer length; besides this returns -1. > Their behavior are different from that of Linux but psqlODBC does not currently make allowances for their differences. > > As you can confirm this bug, I attached a program(test.cpp) which reproduces a bug. Yep. This was already fixed in git master in January, in commit 532c0dad20087201feee3851652c114eb820311f. We're long overdue for a release... - Heikki
> Yep. This was already fixed in git master in January, in commit
> 532c0dad20087201feee3851652c114eb820311f.
Thank you!
I confirmed psql-odbc master is already fixed this bug.
While you are at it, could you fix a precision argument passed to stime2timestamp?
--- C:/work/psqlodbc-a2def3d/convert.c.orig Wed Sep 23 16:14:10 2015
+++ C:/work/psqlodbc-a2def3d/convert.c Thu Sep 24 09:01:50 2015
@@ -1247,8 +1247,7 @@
case PG_TYPE_TIMESTAMP:
/* sprintf(rgbValueBindRow, "%.4d-%.2d-%.2d %.2d:%.2d:%.2d",
std_time.y, std_time.m, std_time.d, std_time.hh, std_time.mm, std_time.ss); */
- len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE,
- (int) (cbValueMax - len - 2) );
+ len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, 6 );
if (len + 1 > cbValueMax)
result = COPY_RESULT_TRUNCATED;
break;
In PostgreSQL, I think max number of digits of precision is always 6.
I hope to be able to use next release as soon as possible.
Regards,
Naoya
---
Naoya Anzai
Engineering Department
NEC Solution Inovetors, Ltd.
E-Mail: nao-anzai@xc.jp.nec.com
---
Hi, psqlodbc commiters. > --- C:/work/psqlodbc-a2def3d/convert.c.orig Wed Sep 23 16:14:10 2015 > +++ C:/work/psqlodbc-a2def3d/convert.c Thu Sep 24 09:01:50 2015 > @@ -1247,8 +1247,7 @@ > case PG_TYPE_TIMESTAMP: > /* sprintf(rgbValueBindRow, "%.4d-%.2d-%.2d %.2d:%.2d:%.2d", > std_time.y, std_time.m, std_time.d, std_time.hh, std_time.mm, std_time.ss); > */ > - len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, > - (int) (cbValueMax - len - 2) ); > + len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, 6 ); > if (len + 1 > cbValueMax) > result = COPY_RESULT_TRUNCATED; > break; > > In PostgreSQL, I think max number of digits of precision is always 6. Could someone confirm this? I think this is a tiny bug.. Best Regards, --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-anzai@xc.jp.nec.com ---
Re: [BUGS] There is a case in which psqlodbc-09.03.0400 returns unterminated strings on Windows.
От
"Inoue, Hiroshi"
Дата:
Hi, Oops it was my mistake. I would take care of it. BTW why is the last parameter 6? regards, Hiroshi Inoue On 2015/11/04 12:53, Naoya Anzai wrote > Hi, psqlodbc commiters. > >> --- C:/work/psqlodbc-a2def3d/convert.c.orig Wed Sep 23 16:14:10 2015 >> +++ C:/work/psqlodbc-a2def3d/convert.c Thu Sep 24 09:01:50 2015 >> @@ -1247,8 +1247,7 @@ >> case PG_TYPE_TIMESTAMP: >> /* sprintf(rgbValueBindRow, "%.4d-%.2d-%.2d %.2d:%.2d:%.2d", >> std_time.y, std_time.m, std_time.d, std_time.hh, std_time.mm, std_time.ss); >> */ >> - len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, >> - (int) (cbValueMax - len - 2) ); >> + len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, 6 ); >> if (len + 1 > cbValueMax) >> result = COPY_RESULT_TRUNCATED; >> break; >> >> In PostgreSQL, I think max number of digits of precision is always 6. > Could someone confirm this? > I think this is a tiny bug.. > > Best Regards, > > --- > Naoya Anzai > Engineering Department > NEC Solution Inovetors, Ltd. > E-Mail: nao-anzai@xc.jp.nec.com
Inoue-san
> Oops it was my mistake.
> I would take care of it.
> BTW why is the last parameter 6?
MAX_TIMESTAMP_PRECISION(a macro in timestamp.h(PostgreSQL)) is always 6.
--- src/include/utils/timestamp.h
#define MAX_TIMESTAMP_PRECISION 6
---
I have confirmed that this specification is not changed from PostgreSQL7.3.
MAX_TIME_PRECISION can be changed 6 to 10 with --disable-integer-datetimes,
but this precision is used by TIME data type only.
---
[naoya@nesitcspg03 ~]$ psql
psql (9.5beta1)
Type "help" for help.
[local] 32289 naoya=# select '2015-11-11 11:11:11.123456789'::time(10);
time
--------------------
11:11:11.123456789
(1 row)
[local] 32289 naoya=# select '2015-11-11 11:11:11.123456789'::time(10) with time zone;
timetz
-----------------------
11:11:11.123456789+09
(1 row)
[local] 32289 naoya=# select '2015-11-11 11:11:11.123456789'::timestamp(10);
WARNING: TIMESTAMP(10) precision reduced to maximum allowed, 6 at character 41
WARNING: TIMESTAMP(10) precision reduced to maximum allowed, 6
LINE 1: select '2015-11-11 11:11:11.123456789'::timestamp(10);
^
timestamp
----------------------------
2015-11-11 11:11:11.123457
(1 row)
[local] 32289 naoya=# select '2015-11-11 11:11:11.123456789'::timestamp(10) with time zone;
WARNING: TIMESTAMP(10) WITH TIME ZONE precision reduced to maximum allowed, 6 at character 41
WARNING: TIMESTAMP(10) WITH TIME ZONE precision reduced to maximum allowed, 6
LINE 1: select '2015-11-11 11:11:11.123456789'::timestamp(10) with t...
^
timestamptz
-------------------------------
2015-11-11 11:11:11.123457+09
(1 row)
[local] 32289 naoya=# select '11.123456789'::interval(10);
WARNING: INTERVAL(10) precision reduced to maximum allowed, 6 at character 24
WARNING: INTERVAL(10) precision reduced to maximum allowed, 6
LINE 1: select '11.123456789'::interval(10);
^
interval
-----------------
00:00:11.123457
(1 row)
---
> >> --- C:/work/psqlodbc-a2def3d/convert.c.orig Wed Sep 23 16:14:10 2015
> >> +++ C:/work/psqlodbc-a2def3d/convert.c Thu Sep 24 09:01:50 2015
> >> @@ -1247,8 +1247,7 @@
> >> case PG_TYPE_TIMESTAMP:
> >> /* sprintf(rgbValueBindRow, "%.4d-%.2d-%.2d %.2d:%.2d:%.2d",
> >> std_time.y, std_time.m, std_time.d, std_time.hh, std_time.mm, std_time.ss);
> >> */
> >> - len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE,
> >> - (int) (cbValueMax - len - 2) );
> >> + len = stime2timestamp(&std_time, rgbValueBindRow, cbValueMax, FALSE, 6 );
> >> if (len + 1 > cbValueMax)
> >> result = COPY_RESULT_TRUNCATED;
> >> break;
Regards,
Naoya
---
Naoya Anzai
Engineering Department
NEC Solution Inovetors, Ltd.
E-Mail: nao-anzai@xc.jp.nec.com
---