Skip site navigation (1) Skip section navigation (2)

Re: Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC

From: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-odbc(at)postgresql(dot)org, 396218-forwarded(at)bugs(dot)debian(dot)org
Subject: Re: Fwd: Bug#396218: bind.c: bad handling of SQL_LEN_DATA_AT_EXEC
Date: 2006-11-07 01:10:18
Message-ID: 454FDCFA.2030108@tpf.co.jp (view raw or flat)
Thread:
Lists: 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(at)debian(dot)org>
> To: Debian Bug Tracking System <submit(at)bugs(dot)debian(dot)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

In response to

Responses

pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2006-11-07 03:34:02
Subject: Re: When length of text data is 1.
Previous:From: Richard Broersma JrDate: 2006-11-06 20:16:05
Subject: Re: Connecting between Postgres(linux) and Access97

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group