FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

> Bug 2:  I don't see what tds is doing for us.  Perhaps the computer is
> curious?    

I assume you are referring to why the conversion stuff is in libtds? 
Basically we had no other place to put it since conversion is shared by
all libraries.  I'm starting to consider that conversion, iconv, thread
safety, and some other miscellenia should be moved somewhere else like a
'common' directory.  It's not protocol related but it is shared among the
API's.

> Bug 3:  Because tds_convert has no dbproc, it can't call the proc's error
> handler.  There are many many places it should call the error handler:
> buffer overflows, null destination pointers, inconvertibility.  This touches
> on Frediano's #578095, and is too big a problem, unfortunately, to deal with
> in 0.60.  

Not true.  You can call tds_client_msg().  The tds layer calls the API's
handler (which unlike the clients handlers are always installed), the
API's handler is then responsible for deciding which application handler
gets called, typically by casting the tds->parent back to a API specific
structure (ala DBPROCESS).
So no, TDS can not call a application handler but he can call the
installed API message handler which can.

Frediano's patch merely deals with the fact that having global API handler
function pointers means that we can not have dblib and ctlib linked to the
same binary and expect messages to work, or worse we'll cast CS_CONNECTION
to a DBPROC and segfault the whole thing.

> --jkl

Brian