FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

[second try; sticky keyboards should not make editors segfault.]

On Mon, Feb 10, 2003 at 11:30:10AM -0500, Lowden, James K wrote:

> Regarding --enable-msdblib, I think we're going to find more and more
> divergence (true by definition, unless and until Microsoft buys Sybase or
> something -- they're not trying to be compatible).  But, perhaps we could
> react at runtime.  That would reduce --enable-msdblib to the same role that
> --with-tdsver plays: setting a default behavior in lieu of a runtime
> setting.  And we could provide a function to set the behavior at runtime,
> offering projects like PHP the ability to switch at will.  

At least in the case of dbdatecrack(), I disagree that users should be
able to control the behavior: except to the extent that the behavior is
dictated by which member of the struct the application chooses to access.
Exposing more options to the user is a poor substitute for good design.

> Steve, what kind of anonymous union would fix the name conflicts in
> dbdaterec at runtime?  That's not a C feature I use very much.  

Probably because, as I remembered upon reflection, it's a Microsoftism
that has only recently been ported to gcc in response to the needs of the
Wine project.  So it's probably not the best route.  Where it works, you
would get something like this:

typedef struct dbdaterec
{
        union {
                DBINT dateyear;
                DBINT year;
        };
        DBINT datemonth;
        DBINT month;
        union {
                DBINT datedmonth;
                DBINT day;
        };
        union {
                DBINT datedyear;
                DBINT dayofyear;
        };
        [...]
} DBDATEREC;

However, since the type of all the members is the same, I don't think the
added protection against accidental name collisions justifies the
portability hit.  I think it's better to use #defines, like so:

#define dateyear year
#define datedmonth day
#define datedyear dayofyear

typedef struct dbdaterec
{
        DBINT year;
        DBINT datemonth;
        DBINT month;
        DBINT day;
        DBINT dayofyear;
        [...]
} DBDATEREC;

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

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

> Regarding 0.61 timing, do we really want to address this now?  I think 0.61
> is basically ready; I'm waiting mostly for access to the website to update
> the news and links.  I appreciate the soname issue (I think), but IMO 0.61
> is signed, sealed, and as ready for delivery as a baby at 9 1/2 months.
> However, I'm ready to follow the consensus if someone whips up the changes
> we need.

I don't have time to work on this immediately, so I'll concede that it's
best to get 0.61 out the door and worry about the msdblib issue for the
next release.  One more soname won't hurt us. :D

-- 
Steve Langasek
postmodern programmer

Attachment: pgp48G1MMvGBa.pgp
Description: PGP signature