Re: [PATCH?] string_transcode

Leopold Toetsch wrote: During chasing the GC bugs one of my patches turned off DOD/GC in string_transcode (which is called from e.g string_compare). There is no need to keep this as the GC issues seem to be solved now. I did apply this during #18097. So the current behaviour matches at least

[PATCH?] string_transcode

During chasing the GC bugs one of my patches turned off DOD/GC in string_transcode (which is called from e.g string_compare). There is no need to keep this as the GC issues seem to be solved now. OTOH e.g. hash.c could profit from the current status, because, when string_compare->string_transcod

Re: [PATCH] string_transcode

In message <007f01c1930c$9d326220$[EMAIL PROTECTED]> "Peter Gibbs" <[EMAIL PROTECTED]> wrote: > Another correction to string_transcode; this function now seems to work okay > (tested using a dummy 'encode' op added to my local copy of core.ops) Applied, thanks. Tom -- Tom Hughes ([E

[PATCH] string_transcode

Another correction to string_transcode; this function now seems to work okay (tested using a dummy 'encode' op added to my local copy of core.ops) Peter Gibbs EmKel Systems Index: string.c === RCS file: /home/perlcvs/parrot/string.c

[PATCH] string_transcode

I suspect that the length of the output buffer for string_transcode should be based on the output encoding, not on the input encoding. Peter Gibbs EmKel Systems Index: string.c === RCS file: /home/perlcvs/parrot/string.c,v retrievin