monotone

Issue 105: Possible incompat with upcoming Botan on x86_64

Reported by Thomas Keller, Nov 12, 2010

Jack Lloyd mentioned that the upcoming Botan 1.9.11 will contain a 
small, but significant change in the filter API:

Filters then use size_t instead of u32bit for most length fields. So 
decl using u32bit will work on 32 bit but
fail on 64 bit size_t's.

He said this should be easy to deal with using some typedef
indirection, but would still be a little obnoxious.

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.
Owner: levitte

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);

Comment 6 by Richard Levitte, May 11, 2012

This appears to have been fixed last autumn, in revision 
754a7a4e12aafce0cf45ab00329f0b6513502066, as part of a larger change 
to compile with Botan 1.10.
Status: Fixed

Created: 13 years 4 months ago by Thomas Keller

Updated: 11 years 10 months ago

Status: Fixed

Owner: Richard Levitte

Followed by: 3 persons

Labels:
Type:Incorrect Behavior
Component:Cryptography
Priority:Medium

Quick Links:     www.monotone.ca    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status