DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21990>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21990
ICULCPTranscoder::transcode memory leak
------- Additional Comments From smorino@xxxxxxxxxxxxx 2003-08-27 17:04 -------
Thaks for your comment to Dave and Neil. :-)
To Dave,
>If you reserve a byte for null-termination, then you will not
>need the code to re-allocate and copy the string as your patch does.
You're right, Dave.
But Junichi and I are living in a country ( It's Japan ) where the encoding is
so complicated. It's impossible to see the bytes required for a transcoded
string before the whole conversion. We have coding systems as 'shift-
JIS', 'JIS', 'euc-jp' and UTF's.
>Yes, you will end up re- transcoding more strings, but I'm not
> convinced making the code more complicated for one edge case is
> worthwhile. Code which can handle all failure cases would not >
> be that much more complicated, if this function is meant to
> be truly efficient.
I agree that it's just an edge case. If you don't mind a cost for reconversion
for the edge case, I can make a simpler patch.
To Neil,
>What I'm most curious about is why this method is using the global new/delete
>and not the pluggable memory mechanisms? Dave, I'd be particulary curious
>about your take on that.
Sorry for that. I forget patching another version of transcode() using a
custom memory allocator.
I'll make a "simpler" patch to support "both" ordinary and 'custom memory
allocator version' of transcode()'s. Please wait a while by the next weekend.
Thanks in advance.
|
