[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No idn_free documentation

From: Simon Josefsson
Subject: Re: No idn_free documentation
Date: Mon, 09 Feb 2009 14:36:44 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

"Sisyphus" <address@hidden> writes:

> ----- Original Message ----- 
> From: "Simon Josefsson" <address@hidden>
>> * The theory of isolating all memory allocations and de-allocations
>> * within a code package (library) sounds good, to simplify hunting
>> * down memory allocation related problems, but I'm not sure if it is
>> * worth enough to motivate recommending this interface over calling
>> * `free' directly, though.
> I hadn't read those comments in idn-free.h.
> I've come across a problem with memory allocation where free() cannot
> be used, and idn_free() is the only solution, afaik.
> With C programs, there's no issue, but when we extend perl to
> interface with libidn, on Win32, free() cannot be used in the XS code
> to free the memory that was allocated by the libidn functions. As soon
> as free() is called we get a "Free to wrong pool ...." fatal
> error. Afaik this happens only on Win32 - it definitely doesn't happen
> on linux.
> So, on Win32, we either have to use idn_free() in the XS code, or
> settle for memory leakage.
> (Again, that's "afaik" :-)
> I think that idn_free() should be documented in (and other
> pertinent places) so that people can readily find it when free() has
> become unusable. And the advice in the documentation, that the memory
> should be freed using free(), should also at least mention the option
> of using idn_free().

You convinced me to document it.  I have pushed this change:;a=commitdiff;h=872fe0483c10c38e9155ab92b79cd7690ac76c9a

> Are there any known cases where idn_free() breaks something that's not
> broken by free() ?

No.  However, I think it makes code harder to read -- any C programmer
knows about the free function, but she would have to lookup what the
idn_free function does in order to understand a program.  So I still
wouldn't want to recommend it for general use.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]