My apologies for the hasty post....it'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 mention of this behavior, and looking at codewarrior's implementation of wcstombs, it clearly does not expect this case. At any rate, it should be safe to modify Win32LCPTranscoder::transcode() to simply allocate 2 bytes per unicode character before transcoding, shouldn't it? Thanks, Geoff On 9/27/01 11:55 PM, "Geoff Coffey" <[EMAIL PROTECTED]> wrote: > 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 the problem lies in > Win32LCPTranscoder::transcode(XMLCh *). This code calls wcstombs() once to > determine the length of the transcoded string, and again to perform the > transcoding. The first call, on our windows 98 environment, returns 0. > Consequently, an empty string is returned. > > I can't fathom why this is failing. I looked at msdn and couldn't find any > valid explanation. The toTranscode XMLCh string is valid (I can view it in > the debugger as a "unicode string" and it looks correct, and again it works > well on win2k). > > Has anyone run in to this before? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
