FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

All, 

Many many API function pass or return null-terminated strings.  The
question I'm wrestling with is how to interpret those strings for
non-ASCII clients.  

Right now, db-lib for instance doesn't track character set very closely. 
You pass dbcmd() a char*; it uses strlen(), strcat(), and strcpy() to fill
the command buffer for you.  The buffer is converted to UCS-2 on the way
out the door, in write.c, if the server is UCS-2.  If your table happens
to have a column "År" (Year), and your character set is set up correctly,
libtds will convert it to UCS-2 and everything works.  At least in theory.
 

Now suppose we want to support a UCS-2 client.  strlen() & Co. become our
nemesis, because a UCS-2 buffer has zeros throughout.  Termination is
signified by 16 zero bits, not 8.  

The question is, should we accept UCS-2 buffers everywhere, and, if so,
how do we know that's what we're getting?  

There are two alternatives I can see:

1.  Accept UCS-2 buffers.  Determine terminator from
DBPROCESS::tds_socket->iconv_info->client_charset.  Write static, local
replacements for strlen() etc. that use client_charset to do the Right
Thing.  Could get interesting for things like DBSETLUSER() that don't have
a dbproc.  Might *have* to rely on nl_langinfo(3) for some things.  

2.  Require buffers in a single-byte character set.  I think this is the
way Microsoft clients work in NT-ish systems.  

I'm interested in your thoughts on these two, or any Third Way you might
have in mind.  

Thanks.

--jkl