Skip to Content.
Sympa Menu

freetds - Re: Crash in tsql

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: Crash in tsql
  • Date: Tue, 13 Aug 2002 12:09:31 -0400


> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: August 12, 2002 10:37 AM
> >
> > > sizeof(*tds) differed between the two, I
> > > just didn't have time to finish it off. config.h should be
> > > included from tds.h (tds.h.in) otherwise we'll have this
> > > problem again in the future.
> >
> > Actually, this fix is bad, since we don't distribute config.h
> > (nor should we) things won't build.
>
> Brian,
>
> I don't understand that sentence. Could you unpack it for me, please?

Ok, config.h is a build time header that doesn't not end up in
/usr/local/freetds/include. It's only there to avoid having a million -D
HAVE_FOO arguments on the make line.

Now, take an application like tsql that may be compiled outside of the
freetds tree. Obviously, it can not rely on the HAVE_* macros being
defined. Since tds.h is distributed (ends up in freetds/include) and used
by third party apps, this is a problem.

> > We simply can't be checking HAVE_ICONV in tds.h (or any distributable
> > header). We could substitute from configure but that strikes me as
> > sloppy. Any other options?
>
> It's not obvious to me what's a "distributable" header and what's not, or
> how HAVE_ICONV is any different from, say, the tests for gethostbyname_r().

gethostbyname checking is contained in .c files and thus does not affect
the compilation of anything outside of the freetds source tree.

> Pretty clearly, we want the HAVE_ICONV test to be done in the configure
> script, and the code to react accordingly. I gather that the way we were
> doing that was causing a problem, but I don't understand what's defeating
> your attempts to fix it.

The basic problem is we conditionally define part of TDSSOCKET based on a
compile time #define, bad form on my part. So, the iconv checking in
configure.in is just fine, how we use it during build is flawed. This
wouldn't be a problem except that iconv_t relies on iconv.h and therefore
may not be available.

I'm still thinking on what would be the most elegant way to handle this,
but basically haven't had a chance to dig into it yet.

> Regards,
>
> --jkl




Archive powered by MHonArc 2.6.24.

Top of Page