Re: leaking iconv handles, wv return type


Subject: Re: leaking iconv handles, wv return type
From: Vlad Harchev (hvv@hippo.ru)
Date: Tue Nov 14 2000 - 12:14:31 CST


On Tue, 14 Nov 2000, Mike Nordell wrote:

 Hi,

 XAP_EncodingManager is assumed to be created no more than 3 times. So I
didn't care about leaking iconv descriptors - they don't take a lot of memory
(no more than 100bytes each). I don't recommend spending time on bothering to
close those descriptors.

> XAP_EncodingManager never closes its opened iconv handles.
>
> I _think_ it's d'tor should set the "instance" variable to zero and then
> call some code like:
>
> void deinit_values()
> {
> iconv_close(iconv_handle_U2Win);
> iconv_close(iconv_handle_Win2U);
> iconv_close(iconv_handle_U2N);
> iconv_close(iconv_handle_N2U);
> }
>
> A quick look at the code suggested these changes would be safe, there might
> be issues I'm not aware of.

 Also, initilize() allocates some memory as I remember. So for consistence it
also should be freed in deinitialize().

> Also, looking at wvLIDToCodePageConverter() (wv/text.c): isn't it a bit
> dangerous to return a non-const char* to those static strings? Without
> knowing the implementation one could easily try to free() the returned
> string (thinking it might be strdup'd).

 It's called in very few places in AW, so the use of return value is under
control.
 Also I think 'char*' in text.c is used instead of 'const char*' for
portability reasons (across C compilers).

> /Mike - please don't cc
>

 Best regards,
  -Vlad



This archive was generated by hypermail 2b25 : Tue Nov 14 2000 - 12:34:19 CST