FreeTDS Development Group

["Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>]

As a long-time lurker on this list, I have to break my silence on this,
although I hate to do so on a negative note after all the great work
Bill's been doing. 

However I recently spent some time tracking down an elusive bug on a
cross-platform application which was due to memory being allocated from
a shared library, and freed from the application mainline. It turned out
that the heap allocation routines from the shared library were different
to those used by the mainline code, and the call to free() failed as it
didn't believe it owned the memory. (Yes, this was on a W2K version of
an application that worked fine on Linux and Tru64, but its best to be
careful.)

Apart from that, is there anyone else on the list running Tru64 who has
been getting good results with recent CVS HEAD code ? I'm testing with
Tru64 4.0f, and have been getting segfaults for a long time now, I've
put it down to unstable code in CVS, or my own setup being in someway
lacking. (The last release worked for me.)

Currently compiling with GCC 3.1.1, but I can't get a good build as yet
due to missing atoll() and tds_answer_challenge() in the libraries,
hopefully that's just a temporary problem ?


David Varley
C-Born Software Systems Pty Ltd
mailto:David.Varley AT ieee.org


-----Original Message-----
From: James K. Lowden [mailto:jklowden AT speakeasy.org]
Sent: Sunday, 4 August 2002 9:28 AM
To: TDS Development Group
Subject: [freetds] convert.c and the next release


All, 

How has the experience been with Bill's new conversion stuff?  Are we
happy?  

I'm a little not, on principle.  But if the new code works, I say it's
high time we kicked it out the door.  

Bill, I'm just not fond of libraries allocating memory and expecting me to
free it.  I would actually prefer, as you said you don't, that tds_convert
use an output buffer provided by the API, and let the API "clear up the
mess afterwards".   

I can think of only two reasons for tds_convert to allocate memory:

1.      The caller doesn't know how big the output buffer should be.
2.      tds_convert wants to give the caller some choice about what to do
with
the output buffer in the event it's not big enough.  

I think case #1 never happens and case #2 is unimportant.  

Other opinions?  Would anyone greatly mind if I slightly rewound Bill's
logic?  It can wait for 0.61.  

But that's a niggle.  The really really great news AIUI is that we have a
complete working datatype conversion matrix.  Do I in fact understand
correctly?  (Curiously, it's not in the ChangeLog.)

Frediano, you have several open patches posted.  It looks like some of
them are OBE (overcome by events, no longer needed).  Could you take a
look and tell me what's still needed, please?  

Brian, I had insight into my iconv problem: On my OSF1 box, libsybdb had
unresolved references to the iconv functions.  I think that's because ar
(?) didn't look in the right place when the library was built, because of
some assumption in the configure script about directories to include.  I'm
going to look into this further.  

I will also fix up tds_willconvert, if only to facilitate testing Bill's
conversion matrix.  I already have a utility that attempts to convert
every column in a result set to every available datatype.  I can post it
if anyone else cares.  

---
You are currently subscribed to freetds as: [David.Varley AT alcoa.com.au]
To unsubscribe, forward this message to
$subst('Email.Unsub')