IconvLCPTranscoder buggy ?

[Miroslaw Dobrzanski-Neumann <mn...@mosaic-ag.com>]

Hi,
looking for bugs in my code I let my application run under control of malloc
debugger (libefence), which reported access violations in `IconvLCPTranscoder'
I am using xerces 1.3.0 under Linux

Here the commented code fragment from IconvLCPTranscoder.cpp
bool IconvLCPTranscoder::transcode( const   XMLCh* const    toTranscode
				    , char* const toFill
				    , const unsigned int
				    maxBytes)
{
	...

	if (maxBytes >= gTempBuffArraySize)
		wideCharBuf = allocatedArray = new wchar_t[maxBytes + 1];
	else
		wideCharBuf = tmpWideCharArr;

[comment] maxBytes can be >> length(toTranscode) => access violation
	for (unsigned int i = 0; i < maxBytes; i++)
	{
		wideCharBuf[i] = toTranscode[i];
	}

	...
}

here the description (fragment) of XMLString::transcode() which calls in
background the IconvLCPTranscoder::transcode()
maxChars  
The maximum number of bytes that the output buffer can hold (not including the
null, which is why toFill should be at least maxChars+1.) If the resulting
output cannot fit into this many bytes, it is an error and false is returned

my understanding of this statement is that I am allowed to provide a output
buffer of an arbitrary size and not of exactly length(toTranscode) + 1

There are other places in this source file (IconvLCPTranscoder.cpp) with the
same bug
-- 
Miroslaw Dobrzanski-Neumann

MOSAIC SOFTWARE AG
Base Development and Research
Tel +49-2225-882-291
Fax +49-2225-882-201
E-mail: mne@mosaic-ag.com

Re: IconvLCPTranscoder buggy ?

[Dean Roddey <dr...@charmedquark.com>]

At some point along the line, I think that the semantics of ICU in this
regard was changed. It is quite possible that we didn't get updated to deal
with that, or did but misinterpreted the new semantics.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"It takes two buttocks to make friction"
    - African Proverb


----- Original Message -----
From: "Miroslaw Dobrzanski-Neumann" <mn...@mosaic-ag.com>
To: "Xerces Dev" <xe...@xml.apache.org>
Sent: Thursday, November 09, 2000 5:44 AM
Subject: IconvLCPTranscoder buggy ?


> Hi,
> looking for bugs in my code I let my application run under control of
malloc
> debugger (libefence), which reported access violations in
`IconvLCPTranscoder'
> I am using xerces 1.3.0 under Linux
>
> Here the commented code fragment from IconvLCPTranscoder.cpp
> bool IconvLCPTranscoder::transcode( const   XMLCh* const    toTranscode
>     , char* const toFill
>     , const unsigned int
>     maxBytes)
> {
> ...
>
> if (maxBytes >= gTempBuffArraySize)
> wideCharBuf = allocatedArray = new wchar_t[maxBytes + 1];
> else
> wideCharBuf = tmpWideCharArr;
>
> [comment] maxBytes can be >> length(toTranscode) => access violation
> for (unsigned int i = 0; i < maxBytes; i++)
> {
> wideCharBuf[i] = toTranscode[i];
> }
>
> ...
> }
>
> here the description (fragment) of XMLString::transcode() which calls in
> background the IconvLCPTranscoder::transcode()
> maxChars
> The maximum number of bytes that the output buffer can hold (not including
the
> null, which is why toFill should be at least maxChars+1.) If the resulting
> output cannot fit into this many bytes, it is an error and false is
returned
>
> my understanding of this statement is that I am allowed to provide a
output
> buffer of an arbitrary size and not of exactly length(toTranscode) + 1
>
> There are other places in this source file (IconvLCPTranscoder.cpp) with
the
> same bug
> --
> Miroslaw Dobrzanski-Neumann
>
> MOSAIC SOFTWARE AG
> Base Development and Research
> Tel +49-2225-882-291
> Fax +49-2225-882-201
> E-mail: mne@mosaic-ag.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>