FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Mon, Feb 10, 2003 at 09:22:32PM -0500, James K. Lowden wrote:

> > Exposing more options to the user is a poor substitute for good design.

> Indeed, no substitute at all.  I'm not sure what choice we have, though. 
> If we want one shared library to behave two ways, that's a runtime option.
>  If we want one source tree to produce two shared libraries with slightly
> different behaviors, that's a configure-time option.  I don't see any
> inherent disadvantages in the former over the latter.  I seem to have
> forgot the advantages, however.  

So far, the discussion has focused on the dbdaterec struct.  Owing to
the differing member names, it seems possible to provide both styles of
behavior simultaneously.  The only concern would be if dblib had another
function that read in a DBDATEREC provided by the application, but I see
no such function in the FreeTDS headers.

Other uses of the MSDBLIB variant ought to be examined on a case-by-case
basis before resorting to a runtime configuration option.

> > using the more esoteric of the names for the member as the alias, to
> > reduce the chance of colliding with app variable names.

> I think we'd live to regret that collision, however remote its probabilty.

The converse of Brian's point is that dblib is already such a mess,
dblib coders are probably used to being cautious with their use of dblib
headers... ;)  Ok, now I'm just being mean-spirited -- do as you see
best here. :-)

> > Failing that, it's always possible to double the structure. <shrug>

> This is safest, but would need a different answer for binary
> compatibility.  

Because DBDATEREC is a public structure, any size changes are also a
binary-incompatible change.  If two separate month fields are to be
included (a minimum requirement if we're providing both sets of
semantics), an ABI change is unavoidable.

-- 
Steve Langasek
postmodern programmer

Attachment: pgp5Jo9XwpUbg.pgp
Description: PGP signature