freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Brian Bruns" <camber AT ais.org>
- To: freetds AT franklin.oit.unc.edu
- Subject: Re: Some API change
- Date: Fri, 16 Aug 2002 14:07:59 -0400
Anything that would be implementing an API level message handler pretty
much has to include tds.h anyway. This whole thing started as one void
pointer, the others were added later and were made consistant with that.
Greg Jensen did the initial implementation I believe in the 1998-99ish
timeframe. There probably was a good reason back then ;-)
Brian
> On Fri, Aug 16, 2002 at 01:40:16PM -0400, Mark J. Lilback wrote:
> > At 12:23 PM -0500 8/16/2002, Steve Langasek wrote:
> > >On Fri, Aug 16, 2002 at 09:11:00AM +0200, Frediano Ziglio wrote:
> > >> I'd like to change some API declaration
>
> > >> 2- use correct pointer type in msg handlers
> > >> int (*msg_handler)(TDSCONTEXT*, TDSSOCKET*, TDSMSGINFO*);
> > >> instead of
> > >> int (*msg_handler)(void*, void*, void*);
> > >> This remove the need to cast at every message handling function
> > >> Note also that this function prototype had been changed from last
> > >> release
>
> > >Normally, this is an advantage because it allows your callback function
> > >to treat the arguments opaquely, so you don't have to include the
> > >library's headers. Is this not useful here? (If you're doing lots of
> > >casting in your message handlers, I suppose not.)
>
> > This is one that's long bothered me, too.
>
> > I generally prefer to have no compiler warnings when I build=20
> > something, and this caused lots of warnings.
>
> > Why/when would it be a problem to include the library's headers?
>
> If you're writing code that doesn't need to directly access the internals
> of the structs, and the library's headers conflict with other headers.
> This may not be a problem here, though, particularly if the callback has
> to call other functions to interpret the structs; I'm just speculating as
> to the possible reason for the code being this way.
>
> Steve Langasek
> postmodern programmer
-
Some API change,
Frediano Ziglio, 08/16/2002
- <Possible follow-up(s)>
- Re: Some API change, Steve Langasek, 08/16/2002
- Re: Some API change, Mark J. Lilback, 08/16/2002
- Re: Some API change, Steve Langasek, 08/16/2002
- Re: Some API change, Brian Bruns, 08/16/2002
Archive powered by MHonArc 2.6.24.