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 [EMAIL PROTECTED] 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
