Comment 1 by Richard Levitte, Nov 27, 2010

So, let me see if I get this right, what he's saying is that he's 
going to change the length parameter in botan/filter.h from u32bit 
to size_t, so it will be possible to give it the result of, say, 
buffer.size() on a machine that does 64 bit size_t's?

That's a good thing but I don't expect this to change anything for 
us, as I expect that in the few places where we do use u32bit, it 
will implicitely expand nicely into 64 bit size_t's.  In other 
places, we directly use .size(), which should fit nicely in a size_t 
on any machine.
(the one thing I can conclude is that monotone won't compile or run 
cleanly on a 64 bit machine with Botan < 1.9.11)

Can anyone try to build the following little hack on a x86_64 
machine?  That should be enough to verify...


#include <cstddef>
#include <botan/types.h>
#include <iostream>
#include <string>

using Botan::u32bit;
using std::size_t;
using std::cout;
using std::endl;
using std::string;

main()
{
  u32bit foo = 0xffffff; // 16777215 decimal
  size_t bar = foo;

  cout << bar << endl;

  string cookie = "A little monkey"; // size is 15
  bar = cookie.size();

  cout << bar << endl;
}

Comment 2 by Ludovic Brenta, Nov 27, 2010

$ file t
t: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
$ ./t
16777215
15
$ 

Also, cout << sizeof (size_t) << endl; correctly outputs 
8 (i.e. 8 bytes i.e. 64 bits).

Comment 3 by Richard Levitte, Nov 27, 2010

Right, perfect...  so now, I guess the only concern would be that 
monotone builds and runs on x86_64.  If you can verify that, I think 
we should close this issue.

Comment 4 by Ludovic Brenta, Nov 27, 2010

I'll try that when botan 1.9 hits Debian unstable (or, before that, 
experimental).

Comment 5 by Jack Lloyd, Apr 18, 2011

I don't think you would need typedefs or anything like that when 
simply using filters; if that had been necessary this would have 
been such a major API change I would have deferred it to being part 
of 2.0 (where filters will probably change substantially to support 
concurrent operation anyway).

However this will cause problems with monotone because monotone does 
actually include a filter *implementation*, in gzip.{hh,cc}, and 
those are broken by this change, because the signatures it 
implements will not match the ones it derives from its Filter base 
(when compiling against 1.9.11+ on 64-bit). That's where the typedef 
indirection comes in;

#if BOTAN_VERSION_CODE >= BOTAN_VERSION_CODE_FOR(1,9,11)
   typedef size_t Filter_length;
#else
   typedef u32bit Filter_length;
#endif

...

class Gzip_Compression : public Filter {
...
      void write(const byte input[], Filter_length length);