Date: Tue, 20 Jan 1998 21:27:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: daniel_sobral@voga.com.br Cc: louie@TransSys.COM, hackers@FreeBSD.ORG Subject: Re: Wide characters on tcp connections Message-ID: <199801202127.OAA27796@usr06.primenet.com> In-Reply-To: <83256592.0040388D.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Jan 20, 98 08:43:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As far as my question goes, that was not the issue. The issue is the
> existance, or not, standards for transporting wide characters over TCP, in
> a higher layer.
If a wchar_t is correctly interpreted as a 16 bit value, then I think
the answer is "yes".
For wchar_t data sent raw, I would say it should be htons/ntohs'ed.
For wchar_t data sent via SMB, I would say Intel byte order
For wchar_t data sent via RPC, I would say XDR (htons/ntohs'ed).
For wchar_t data sent via DCE/RPC, I would say "source host byte order
with byte order indication"... in other words, exactly what DCE/RPC
does for any short or long value.
FWIW, Unicode supports two code points for use in determining byte
order ("normal order" vs. "inverted order") and assumes 16 bits;
AFAIK, ISO10636 did not extend this in the compatability space to
account for the additional 32 bit word order possibilities. This
is a good reason to treat wchar_t as a 16 bit value.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801202127.OAA27796>