[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: http://code.monotone.ca/p/monotone/issues/105/
Labels:
 Type:Incorrect Behavior
 Component:Cryptography
 Priority:Medium

Comments (last first):

# 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: http://code.monotone.ca/p/monotone/issues/105/