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
