FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Mark J. Lilback [mailto:mark AT lilback.com]
> Sent: April 11, 2003 9:16 AM
> 
> At 7:41 AM +0200 4/11/2003, Frediano Ziglio wrote:
> >Yes, iconv_t do not exists in win32.. Also Mac OS X have different
> >functions...
> 
> iconv works on Mac OS X, it just isn't installed by default. I'd just 
> prefer to add in support for the native Mac OS X character set 
> translations so that I don't have to compile in iconv statically 
> (adding a lot to the file size) when I distribute the freetds dynamic 
> libraries with my application.

This sounds completely reasonable to me.  I want my work to support yours,
so if I get in your way somehow, please shout.  

> I started working on an implementation of iconv that uses the native 
> translation facilities, but it ends up having one problem. It also 
> requires mapping all the iconv charset names to the Mac OS constants 
> for each character set (I already did Unicode, but with the new 
> changes I'll need to work on other character sets, too). 

What at drag, eh?  Isn't the problem hard enough without having to cope with
nonstandard identifiers?  

I'm going to provide a function that will accept a name and return the
standard name.  AIUI, there are some nonstandard names whose meaning is
ambiguous; those will return NULL.  We need a similar function to return
Sybase/Microsoft names when passed a standard name.  

OS X uses integers instead of strings?  That's intelligent, but I can't
believe you're the first guy to need a mapping to cannonical names.  How do
you print the character set name?  

> There also 
> appears no way to get "the number of non-reversible conversions 
> performed" that is returned by iconv.

That's one reason I'm going to change the tds_iconv signature to match
iconv's.  I have to believe Bruno Haible knows what he's doing, no reason
not to follow his lead.  

> Testing will be hard

Yup.  

> I will need to finish this implementation before James finishes his 
> changes, however. Right now I'm using a hacked up version of iconv 
> that only supports the unicode, isolatin 1-14, and macroman variants. 

I think we're back to baseline functionality (Latin clients and UCS-2
servers), and even perturbing tds_iconv isn't likely to change that.  Next
stop for me is UTF-8 clients.  Then UCS-2 clients.  For that, we have to zap
practically every strlen() in the system, and ensure that every such
reference relates to the byte count.  At least, that's been my working
hypothesis.  

--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.