Re: Memory access bug in XMLString2Perl()

Hi Chris,

Chris Cheung <[email protected]> writes:

>   I am currently using Xerces-C 2.3.0 and Xerces-Perl 2.3.0-4.
> 
>   When I use valgrind (a popular memory debugger, 
> (http://valgrind.kde.org/) to check the following simple program:

Hah! You beat me to it. I found valgrind the other week, but
unfortunately it is an i386 specific tool (I do all my development on
a powermac).

> SV*
> XMLString2Perl(const XMLCh* input) {
>     SV *output;
>   unsigned int charsEaten = 0;
>   int length  = XMLString::stringLen(input);      // string length
> 
>   XMLByte* res = new XMLByte[length * UTF8_MAXLEN];          
>      // output string
> 
>   unsigned int total_chars =
>     UTF8_TRANSCODER->transcodeTo((const XMLCh*) input,
>                    (unsigned int) length,
>                    (XMLByte*) res,
>                    (unsigned int) length*UTF8_MAXLEN,
>                    charsEaten,
>                    XMLTranscoder::UnRep_Throw
>                    );
>   res[total_chars] = '\0';
> 
> The memory to malloc should be (length * UTF8_MAXLEN + 1):
> 
>   XMLByte* res = new XMLByte[length * UTF8_MAXLEN + 1];          // output 
> 
> so that the memory for the ending '\0' is not missed.

Does changing this make a difference? I would be surprised - the call
to transcode to gives the *maximum possible length* for the buffer,
and returns the *actual* length used. Does changing this make valgrind
happy? I've got no objection to adding this to the code, I'm just
curious. 

Cheers,
jas.