memory leaks

[Dirk Stoecker]

On Thu, 12 Jan 2006, Marcus Brinkmann wrote:

> > I am 
> > nevertheless required to have this page released due to the LGPL license 
> > of libgcrypt.
> 
> You are required to comply with the conditions of the LGPL.  These
> conditions say nothing about a web page.

It is one of the cheapest forms of complying to LGPL/GPL.

> being ignored completely.  You say you don't want to spend any amount of
> time to make the patches perfect and separate when getting ignored.
> However, why do you expect that we spend this time to make the patches
> perfect and separate if we don't even know what they would do?

Because I already had multiple time bad experience and don't believe 
additional work will help.

I will no longer discuss this part about who is to blame for what as like 
always this brings nothing for both sides. Any further discussions 
restricted to the helpful parts of technical issues.

> > You have better insight into the topic to 
> > find out, how this would be needed to be implemented, as reference 
> > counting in the current state with automatic initializer calls is a bit 
> > complicated.
> 
> I don't understand what's complicated about it.  Can you elaborate?

Reference counting would require exactly one INIT and one FINISH for each 
party using the software. As there are "automagically" initialisations in 
some calls, it may be complicated to track down different parties (e.g. 
libraries, which do no explicit init call). I do not know the internals 
well enough to decide how exact reference counting would be. It is always 
more complicated to implement such stuff in existing code, where it has 
not been designed from the very beginning.

This greatly depends on the real world usage of libgcrypt. Probably a 
first step would be an assertion for these cases, so that the programmers 
get an information and implement explicit init and shutdown calls. In 
the time inbetween the finalize call would not release anything and a 
configuration option in autoconf would toogle dummy/real-mode.

Maybe the best would be the introduction of "contexts" into the API/ABI as 
additional option and having a global context for legacy applications as 
Frediano explained in his mail. Using the deprecated attribute and proper 
texts how to fix it in the header file will make updating of legacy 
applications much easier. It would not break ABI and API.

In 2-3 years the deprecated stuff and the global context can be removed
(breaking the API) and the problem is solved. Thought before this the 
new API must be designed or there will be incompatible changes for 
libgcrypt 2 again.

Ciao
-- 
http://www.dstoecker.de/ (PGP key available)