My understanding now is that the standard specification for wcstombs does
not dictate that if a buffer size of zero is passed in, the size needed
should be returned. This seems only to be a (documented) side effect of the
implementation in VC++ and Borland. It also doesn't dictate that the
wchar_t
Goeff and Dean,
After looking at the C RTL sources for both Borland and MSVC, wcstombs()
returns -1 on errors using either compiler. The Borland documentation
states "If an invalid multibyte character is encountered, wcstombs returns
(size_t) -1. Otherwise, the function returns the number of
On 9/28/01 12:50 AM, "Dean Roddey" <[EMAIL PROTECTED]> wrote:
> No, definitely not 2 bytes. UTF-8 can take up to 6 bytes to hold a single
> Unicode character, and others can take 3 or 4 and whatnot. You really need
> to know what the target is going to take. And you can't really afford to do
> a
> At any rate, it should be safe to modify Win32LCPTranscoder::transcode()
to
> simply allocate 2 bytes per unicode character before transcoding,
shouldn't
> it?
>
No, definitely not 2 bytes. UTF-8 can take up to 6 bytes to hold a single
Unicode character, and others can take 3 or 4 and whatnot.
My apologies for the hasty postit's late :)
In looking a little more, it looks like wcstombs is not _supposed_ to return
the needed size when the buffer pointer is null, although MSDN documents it
this way, so I assume it does work this way in MSVC++??
But in every other reference, I see no
Ok, thanks to those who addressed my previous questions. I have one more
question, this time on the windows side.
Our windows work was done on Windows 2000, and everything worked well. But
we received reports from testers that it was not working on Windows 98. In
digging through it, I see that th
