[Botan-devel] load_key() functions

Boris boriss at web.de
Tue Sep 25 15:47:00 EDT 2007


> -----Original Message-----
> From: botan-devel-bounces at randombit.net 
> [mailto:botan-devel-bounces at randombit.net] On Behalf Of Jack Lloyd
> Sent: Tuesday, September 25, 2007 10:24 PM
> To: botan-devel at randombit.net
> Subject: Re: [Botan-devel] load_key() functions


thanks for your fast reply! 

> On Tue, Sep 25, 2007 at 09:27:15PM +0300, Boris wrote:
> > Hi everyone, 
> > 
> > the various PKCS8::load_key() and X509::load_key() 
> functions all return a
> > pointer to Private_Key respectively Public_Key. From what I 
> understand the
> > keys are dynamically allocated and ownership is passed to 
> the caller (which
> > means the caller must not forget to delete the keys)? If 
> that is true
> > wouldn't it be better to return std::auto_ptr<Private_Key> 
> respectively
> > std::auto_ptr<Public_Key>?
> Perhaps, yes. Clearly a raw, dynamically allocated pointer is a recipe
> for trouble (and I know most of the time I call those functions, I do
> assign the result directly to an auto_ptr). However I'm hesitent to
> adopt too much policy, and in particular when auto_ptr is really not a
> very good solution in a lot of cases.. A Boost/TR1 shared_ptr would be
> a lot better and something I would consider using when available;
> something I'm going to have to contemplate is how much of TR1/C++0x
> Botan is going to use, and how quickly - there may well be a long
> lived C++0x branch that at some point becomes the mainline. Concepts,
> `auto`-based type inference, lambdas, move semantics, and the new for
> loop all look like they would be very useful for making the library
> smaller and more functional. (But for the moment I'm staying with
> C++03 functionality which throws out shared_ptr and the rest).

No problem for me. I only want to add that in my opinion using a shared_ptr
is not preferable as once a resource is held by a shared_ptr you can't
release it anymore. This is a problem if you use for example specialized
containers like boost::ptr_vector (see
http://www.boost.org/libs/ptr_container/doc/ptr_container.html) which have
been optimized to hold dynamically allocated objects. With a raw pointer or
an auto_ptr you can write code like this: 

boost::ptr_vector<Public_Key> publickeys; 

The important part is that ownership must be passed to the ptr_vector
container. If load_key() returns a shared_ptr you can't use
boost::ptr_vector and other optimized containers anymore as you can't pass
ownership. If load_key() returns an auto_ptr though you can still release it
and store it in a shared_ptr if preferred. 

> [...] 
> The actual type of the key will vary dynamically depending on the
> contents of whatever you just loaded the key from (a file or buffer,
> etc). Typically the key's type will not be known before runtime, so we
> have to return a polymorphic type. If you examine the declaration of
> Public_Key and Private_Key, you'll see they are purely interface
> specifications - and in fact the interfaces provided there only

Thanks for your explanations - make sense to me! :) 


> [...] 

More information about the botan-devel mailing list