Re: [PATCH] Dynamic SSL Certificate Generation

Sorry, in my last mail I have errors in examples about using the
TidyPointer. The deallocator function given as template parameter, not
as constructor parameters:
     TidyPointer<A,freeA> a(newA());

and NOT :
     TidyPointer<A> a(newA(),freeA);

On 11/11/2010 12:38 PM, Tsantilas Christos wrote:
> On 11/11/2010 03:11 AM, Amos Jeffries wrote:
>> On Wed, 10 Nov 2010 17:05:16 +0200, Tsantilas Christos
>>>
>>> * Introduce the TidyPointer class similar to std::auto_ptr, which
>>> implements a pointer that deletes the object it points to when the
>>> pointer's owner or context is gone. It is designed to avoid memory
>>> leaks in the presence of exceptions and processing short cuts.
>>
>> So whats different about this new pointer type that the existing
>> std:auto_ptr, RefCount::Pointer and CbcPointer are all insufficient?
>
> The TidyPointer is completely different than RefCount and CbcPointers.
>
> It is similar to the std::auto_ptr but allow developer to define the
> deallocator method for the object it points to.
> Also does not implement the "=" operator and prevents developers from
> using the copy constructor.
>
> It can be usefull when you have code as the following:
> -----------------------
> A *a= newA();
> if (!a)
> return NULL;
> B *b=newB();
> if (!b) {
> freeA(a);
> return NULL;
> }
> C *c=newC();
> if (!c) {
> freeA(a);
> freeB(b);
> return NULL;
> }
>
> If(problem){
> freeA(a);
> freeB(b);
> freeC(c);
> return NULL;
> }
> return C;
>
> Using TidyPointer the above can be written as:
>
> TidyPointer<A> a(newA(),freeA);
> if (!a)
> return NULL;
> TidyPointer<B> b(newB(),freeB);
> if (!b)
> return NULL;
> TidyPointer<C> c(newC(), freeC);
> if (!c)
> return NULL;
>
> if (problem)
> return NULL;
> return C.release();
>
>
> Can help you to avoid memory leeks when you have the following case:
>
> A *a= newA();
> DoSomeWorkWhichMayThrow(a);
> freeA(a);
>
> In the above case if the DoSomeWorkWhichMayThrow() throws the a object
> will never be released.
>
> The above can be written:
>
> TidyPointer<A> a(newA(),freeA);
> DoSomeWorkWhichMayThrow(a.get());
>
>>
>>> From what I've heard of the SSL problems they are all cause by it not
>> using RefCount on the contexts themselves.
>>
>
> Maybe RefCount is usefull for the SSL_CTX objects. But I do not think it
> is required.
>
> In most cases using the openSSL library you have code like the following:
>
> a=NewA();
> b=newB(a);
> if (!b) {
> freeA(a);
> }
> else {
> //Just forget the a
> }
>
> I these cases the TidyPointer is very useful.
>
> Regards,
> Christos
>
>
Received on Thu Nov 11 2010 - 11:21:00 MST