Use fixed-width int types for portability

[tromer]

Libsnark currently uses long ~~long~~ and unsigned long ~~long~~ in many places. On native Windows build, these are 32-bit types (even on 64-bit Windows), which breaks compatibility (#26) and in some cases correctness (e.g., #13).

Convert all of these to C++11 fixed-width integer types: int64_t and uint64_t.

Except where they should be size_t instead (e.g., https://github.com/zcash/zcash/issues/1240).

(Ongoing work by @radix42 and @joshuayabut.)

[daira]

Are we sure it is long long (rather than long) that is 32 bits? C99 requires long long to be at least 64 bits.

[radix42]

Its long and unsigned long that are all over libsnark, and which are 64 bits on linux but 32 bits on Windows (even Win64)

On Jan 27, 2017 2:40 PM, "Daira Hopwood" [email protected] wrote:

Are we sure it is long long (rather than long) that is 32 bits? C99 requires it to be at least 64 bits.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scipr-lab/libsnark/issues/66#issuecomment-275782034, or mute the thread https://github.com/notifications/unsubscribe-auth/AF9e0Lm3gyHcATjrC5VhYIjI0dmcCdFbks5rWmRmgaJpZM4LvIpE .

[jmprcx]

To add onto what @radix42 mentioned.. Even size_t is potentially problematic (32 bits on Win64 vs 64 bits on Linux/Unix).

[tromer]

The difference in the size of size_t shouldn't matter, as long as it's used correctly (i.e., just for sizes, array indices, etc.) rather than data (e.g., bigint limbs).

Platform dependencies may arise when it needs to be cast into other integer types (or in overloading); but these should be caught at compile/link time, and in this case it makes sense to have an explicit cast.

See discussion and example in https://github.com/zcash/zcash/issues/1240.

[daira]

size_t is 64 bits on Win64.