Jeff,
no there was no reason why I used the apr_int16_t type. I was only happy
that I got the oracle driver on AIX working and did not go further into
details... So go ahead!
Regards,
Stefan
On 23.03.2011 19:01, Jeff Trawick wrote:
I was looking at
http://svn.apache.org/viewvc?view=revision&revision=1065258 in
consideration of getting it in apr-util 1.3.11 and in doing some
research (finally found
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/ociaahan.htm#sthref5358)
I realized there's a signed-ness issue with the fix. (ub2 == unsigned
short, apr_int16_t == signed short)
No big deal, but I wonder: Is there a good reason to avoid oci datatypes here?
Index: apr/dbd/apr_dbd_oracle.c
===================================================================
--- apr/dbd/apr_dbd_oracle.c (revision 1084642)
+++ apr/dbd/apr_dbd_oracle.c (working copy)
@@ -178,7 +178,7 @@
define_arg *out;
apr_dbd_t *handle;
apr_pool_t *pool;
- int type;
+ ub2 type;
};
/* AFAICT from the docs, the OCIEnv thingey can be used async
@@ -860,7 +860,6 @@
int ret = 0;
int i;
apr_dbd_prepared_t *stmt ;
- apr_int16_t type;
if (*statement == NULL) {
*statement = apr_pcalloc(pool, sizeof(apr_dbd_prepared_t));
@@ -896,12 +895,11 @@
apr_pool_cleanup_null);
/* Perl gets statement type here */
- sql->status = OCIAttrGet(stmt->stmt, OCI_HTYPE_STMT,&type, 0,
+ sql->status = OCIAttrGet(stmt->stmt, OCI_HTYPE_STMT,&stmt->type, 0,
OCI_ATTR_STMT_TYPE, sql->err);
if (sql->status != OCI_SUCCESS) {
return 1;
}
- stmt->type = type;
/* Perl sets PREFETCH_MEMORY here, but the docs say there's a working
default */
#if 0
