[Monotone-devel] Updated Issue 105 - Possible incompat with upcoming Botan on x86_64 (monotone)

[code]

Hello,

The following issue has been updated:

105 - Possible incompat with upcoming Botan on x86_64
Project: monotone
Status: New
Reported by: Thomas Keller
URL: https://code.monotone.ca/p/monotone/issues/105/
Labels:
 Type:Incorrect Behavior
 Component:Cryptography
 Priority:Medium

Comments (last first):

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

# By Ludovic Brenta, Nov 27, 2010:

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

# 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

# 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).

# 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;
}

# 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.



--
Issue: https://code.monotone.ca/p/monotone/issues/105/