I'm compiling and exclusively using 64bit.
Generally C++ style casts should be used instead of C casts.
But otherwise I think apart from these few cases (that are now fixed), the
code is generally using size_t.

> Yes, my mistake - thanks. The change should have been to make step and
> start int (vs. size_t).
>
> There is quite a bit of implicit coercion between fixed length and
> architecture-based integer variables, in both the libbitcoin and zmq
> projects. I always compile for 32 and 64 bit and it seems evident that
> these problems would be caught early if developers regularly compiled
> for 64 bit architecture.
>
> I've made a number of corrections in areas that looks safe (despite this
> mistake) although others require deeper surgery to be done properly. I'm
> not comfortable doing that without a comprehensive test suite or at
> least an ability to manually investigate each code path (which I'm not
> up to yet).
>
> If data types are being chosen for the right reasons then explicit
> casting should be used when conversion is necessary and intended. And
> when an cast occurs it's a sign that an upstream guard must be in place
> to handle the potential error.
>
> e
>
> On 04/06/2014 08:56 AM, Amir Taaki wrote:
>> hey eric,
>>
>> I had to change this as it was causing obelisk to throw std::bad_alloc.
>>
>> https://github.com/spesmilo/libbitcoin/commit/1f8cdf58c3a42ccccfa33516d528b000aee0a53e
>>
>
>