Skip to Content.
Sympa Menu

freetds - RE: [freetds] Header privatization

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Header privatization
  • Date: Tue, 23 Mar 2004 17:05:57 +0100

>
> On Tue, 23 Mar 2004, "ZIGLIO, Frediano, VF-IT"
> <Frediano.Ziglio AT vodafone.com> wrote:
> > Yesterday I spent some time privatizing CTLib headers. The aim is to
> > avoid implementation detail in headers so we can change
> implementation
> > mantaining binary compatibility.
>
> Sounds good, as long as they remain forward references, and
> don't become
> opaque handles.
>
> As you say, if the application uses the structures safely --
> in the way
> they're designed to be used, and in the way they're
> documented -- there's
> no need to hide any implementation details. And, certainly, there's a
> disadvantage: the data structures become harder to debug.
> Instead of a
> pointer to a structure, you get an opaque handle that
> requires an arcane
> cast to dereference.
>

They are not void* pointer they are pointer to undefined types. That is
structure are declared like

typedef struct _type* TYPE;

For clients it's a undefined type but for source it's a defined type
(just cause you include private header). For debugger you have all
information cause they get included in library when you compile source
library. For a good debugging you need all source so you have also
private include.

> In working with the ODBC library lately, I found its opacity both a
> nuisance and a hinderance to working with the code.
>

ODBC it's a harder cause handles came from DM, not from library...

> I agree, a FreeTDS ct-lib program could choose to inspect the
> structure
> rather than use a (safe) function call. But the structure is
> superficially undocumented and subject to change. Anyone
> biting into that
> bitter fruit is due for a taste of it.
>
> As far as changing the headers goes, the other important
> thing to my mind
> is to remove db-lib-isms. Each library has its own set of
> constants, and
> it's to our advantage if, say, "success", with all its
> different names,
> always resolves to the same constant. But there are
> definitely times in
> libtds when we use a db-lib constant, and that can get in the
> way. And
> there's no need for TDS constants in the sybdb.h.
>

This is the harder things... I had to copy some structure/constants and
test for consistency (see at top of ctutil.c)... I don't like that
much...

....

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page