Re: Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC
От | Hiroshi Inoue |
---|---|
Тема | Re: Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC |
Дата | |
Msg-id | 454FDCFA.2030108@tpf.co.jp обсуждение исходный текст |
Ответ на | Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC breaks passing char buffer length at SQLExec time (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC breaks passing char buffer length at SQLExec time
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-odbc |
Peter Eisentraut wrote: > A Debian bug report ... Enrico is right at the point that the evaluation of *pcbValue here is dangerous and has no meaning. So in my version I already invalidated the code(#ifdef NOT_USED). Unfortunately his patch seems to have no meaning. regards, Hiroshi Inoue > ---------- Forwarded Message ---------- > > Subject: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC breaks > passing char buffer length at SQLExec time > Date: Monday 30 October 2006 17:00 > From: Enrico Zini <enrico@debian.org> > To: Debian Bug Tracking System <submit@bugs.debian.org> > > Package: odbc-postgresql > Version: 1:08.01.0200-2 > Severity: normal > Tags: patch > > Hello, > > thanks for maintaining odbc-postgresql. > > In my package dballe (apt-get source dballe) I optimize some frequent > query by preparing the ODBC statement for them and binding the input > parameters, so that when I need the results I can just set some of the > bound variables and call SQLExecute. > > This is an example of such variable bind code: > > SQLBindParameter(res->istm, 3, SQL_PARAM_INPUT, SQL_C_CHAR, > SQL_CHAR, 0, 0, &(res->value), 0, &(res->value_ind)); > > Note that I'm passing a pointer to the variable that will hold the > string length as the last parameter, instead of using SQL_NTS. > > Now, this call eventually ends up in this code, found at bind.c:118: > > /* Data at exec macro only valid for C char/binary data */ > if (pcbValue && (*pcbValue == SQL_DATA_AT_EXEC || > *pcbValue <= > SQL_LEN_DATA_AT_EXEC_OFFSET)) apdopts->parameters[ipar].data_at_exec = > TRUE; > else > apdopts->parameters[ipar].data_at_exec = FALSE; > > This code tries to dereferenciate the (still uninitialised) pointer I > pass it ( that &(res->value_ind) ) and fails. The test should be like > this instead: > > /* Data at exec macro only valid for C char/binary data */ > if (pcbValue && (pcbValue == SQL_DATA_AT_EXEC || > pcbValue <= > SQL_LEN_DATA_AT_EXEC_OFFSET)) apdopts->parameters[ipar].data_at_exec = > TRUE; > else > apdopts->parameters[ipar].data_at_exec = FALSE; > > ODBC has this dirty habit of passing negative integers as special > values for pointers, and SQL_DATA_AT_EXEC is one of those: > > from /usr/include/sql.h:29: > > #define SQL_NULL_DATA (-1) > #define SQL_DATA_AT_EXEC (-2) > > same goes for the handling of SQL_LEN_DATA_AT_EXEC_OFFSET. > > I regret I can't test the patch with code that uses SQL_DATA_AT_EXEC, > because that is an ODBC feature that I do not use. However, with the > patch my SQLBindParameter above works fine. > > > Ciao, > > Enrico
В списке pgsql-odbc по дате отправления:
Предыдущее
От: Richard Broersma JrДата:
Сообщение: Re: Connecting between Postgres(linux) and Access97