On Wed, Mar 14, 2012 at 02:00:19PM +0000, Martin J. Evans wrote: > > > >>There are cases where an imp_sth is passed as a parameter yet > >>D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh > >>pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for > >>example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in > >>the function to be imp_sth instead. There may be cases where the same > >>applies with imp_dbh. > > > >Yeah, thanks, I'll fix those. > > Those D_imp_xxh calls in dbd_st_fetch and dbd_bind_ph are simply there > because those fns call DBIh_SET_ERR_CHAR and that takes an imp_xxh_t. > I have removed them but then I need to cast imp_dbh/imp_sth to > imp_xxh_t before calling DBIh_SET_ERR_CHAR so that then makes we > wonder why imp_xxh_t is really required? just so you can pass an > imp_dbh_t or an imp_sth_t to it? > > The only places DBD::ODBC using imp_xxh_t is in calls to > DBIh_SET_ERR_CHAR and DBIc_TRACE (and a few calls to DBIc_TYPE). So > are you effectively saying imp_xxh_t exists for the simple reason it > could be either an imp_sth_t/imp_dbh_t and if that is so I presume I > can just delete all D_imp_xxh macros where the imp_xxh is passed to > DBIh_SET_ERR_CHAR/DBIc_TRACE, pass the real imp_*h and cast it and > avoid a call to dbih_getcom2?
Yes. imp_xxh_t gives access to those struct elements that are common to all handles. It's always safe to cast a imp_??h_t to imp_xxh_t. Tim.
