Re: 2 bytes per character
Alex Blekhman <xfkt@oohay.moc> wrote:
"Igor Tandetnik" wrote:
What precisely would stop one from putting a surrogate
pair into a BSTR? It just carries bytes around. In what
sense may BSTR "not support" surrogate pairs?
Of course, nothing can stop developer from putting surrogate
pair into BSTR. The problem with "support" can arise from
other components that work with BSTR. (Not to speak of being
prohibited by OLE specification.) For example, SysStringLen
will return incorrect length
It will return the length in wchar_t's, consistent with all the other
Win32 APIs.
marshalling such BSTR will
corrupt its content
Are you sure? Corrupt in what way? As far as I can tell, BSTR is treated
as a binary buffer for marshalling purposes. It may even have an odd
number of bytes.
I'm not sure that in all those places no assumptions
were made about content of BSTR.
I don't think there are any assumptions about contents of BSTRs in COM
runtime - witness SysAllocStringByteLen et al.
I can bring an example of such assumptions. One day we tried
to transmit binary data via BSTR. Such usage is allowed by
OLE Automation and described in SysAllocStringByteLen
documentation. So, embedded zeros should be "suppored" by
BSTR. However, it was proven with simplest example that DCOM
marshalling code (or whatever else) assumed that BSTR won't
contain zero in the middle.
Can you show a repro? I've dealt with BSTRs containing embedded NULs on
a few occasions, and I believe COM runtime handles these just fine. Is
it possible you were using some library on top of raw COM that choked on
these? E.g. most methods of ATL's CComBSTR would trunctate a string with
embedded NULs.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925