Skip to Content.
Sympa Menu

freetds - [freetds] Freedom from iconv day

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'TDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: [freetds] Freedom from iconv day
  • Date: Mon, 7 Jul 2003 15:41:45 -0400

All,

Befitting the date, on 4 July I committed changes that enable FreeTDS to
convert UCS-2 data to/from ISO-8859-1 or ASCII without libiconv.
Functionally, this restores the status quo ante; our recent libiconv
dependency was an accident that's now been fixed.

There is a new feature concerning how related errors are handled. If we
cannot convert data on the way to the server, we emit message 2402 and
return an error. If we cannot convert data on the way to the client, we
emit message 2403 as a warning, and replace each unconvertible character
with '?'. The error numbers, text, and severity emulate the messages
emitted by Sybase servers in similar situations. FreeTDS also emits
messages 2401 and 2400 (which afaik Sybase does not) to indicate
insufficient buffer space.

There were two internal modifications of potential interest. One,
tds_iconv() got a new signature which proved easier to work with than its
first incarnation. Two, if no libiconv is detected, we rely on our
simple-minded built-in replacement.

If you're examining or changing the code with respect to character
conversion, you may wish to keep in mind my intention: all character data
pass through tds_iconv(). That function will detect the no-op case (no
conversion needed), for which it will simply copy input to output.
Consequently, the test #if HAVE_ICONV is now highly specialized, reduced to
determining which header files to include and which definitions to provide
in the absence of iconv.h.

We are now positioned to complete the work of handling per-column
conversions (TDS 8.0) and cleaning up the UCS-2 assumptions in parts of
libtds. These should lead to continued progress toward complete support for
UTF-8 clients.

I would be very glad for any feedback on snapshots that include these
changes, especially on big endian or 64-bit clients (neither of which I
own).

Looking over TODO, I see we've addressed the better part of the iconv
issues. As I see it, things are stabilizing further; the list of broken
things is getting shorter again. That bodes well for a 0.62 release in the
fall.

May all your data be normal.

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page