[Botan-devel] RFC: memory locking

Joel Low joel at joelsplace.sg
Wed Nov 14 22:04:04 EST 2007


Hello,

I've got a minor question for doing this though. MemoryRegion::append has three overloads:

      void append(const T data[], u32bit n)
         { grow_to(size()+n); copy(size() - n, data, n); }
      void append(T x) { append(&x, 1); }
      void append(const MemoryRegion<T>& x) { append(x.begin(), x.size()); }

std::vector::push_back doesn't have any:

void push_back(const T& val);

The only way of "renaming" the other two overloads will be to use std::vector::insert(iterator i, iterator start, iterator end); The std::vector class does not have an append member if memory serves me right.

The good thing about unifying the container used will be that using the STL memory can be passed in/out of Botan without a need for reallocation and copying (or the uglier pointer coercion). However, I'm not too certain if removing the member would break applications though (I believe one of my older, few-month-old application did use it, but that's being superseded by a new version).

Regards,
Joel

> -----Original Message-----
> From: botan-devel-bounces at randombit.net [mailto:botan-devel-
> bounces at randombit.net] On Behalf Of Jack Lloyd
> Sent: Thursday, 15 November, 2007 2:13 AM
> To: botan-devel at randombit.net
> Subject: Re: [Botan-devel] RFC: memory locking
> 
> On Tue, Nov 13, 2007 at 08:47:18AM +0100, Christoph Ludwig wrote:
> 
> > But more important, I think, is that the container used by Botand
> > adhere to the standard containers' concepts; i.e., that they meet
> > all the requirements laid down in chapter 23 of the current
> > standard. That helps a lot if the Botan containers need to be used
> > in combination with other libraries.
> 
> Step 1 of ? of this:
> 
> MemoryRegion::append() becomes push_back()
>    [revid 3b7bfdf4cd9ce82f6af404bed00d6369b38a5945]
> 
> The obvious question: Why am I not just adding new members and leaving
> append() be? One conceivable (and IMO somewhat attractive) path here
> is to allow for these types to be transparently replaced with
> std::vector<> or equivalent in any particular build of the library,
> but that only works if callers are restricted to the API provided by
> the container concepts. (Also because I'm betting this change will not
> break any applications, though I'm sure I'll hear about it if that's
> not the case).
> 
> -Jack
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://www.randombit.net/mailman/listinfo/botan-devel




More information about the botan-devel mailing list