[freetds] UCS-2 strings
James K. Lowden
jklowden at schemamania.org
Mon Apr 14 01:41:39 EDT 2003
Many many API function pass or return null-terminated strings. The
question I'm wrestling with is how to interpret those strings for
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.
More information about the FreeTDS