Re: Rethinking octave_idx_type

[Michael D Godfrey]

Currently we define octave_idx_type to be the same as the integer type used by BLAS, LAPACK, and other functions that have a "Fortran" interface.  By default, this means 32-bit integers even on 64-bit systems and arrays are limited to less than 2^{^31} elements.  This affects all of Octave, even if you don't actually want to pass large arrays to the functions that actually have these size limits.

Instead, it seems that we could define octave_idx_type to be ssize_t (or ptrdiff_t, I think they are equivalent in practice).  Then things like fread, fwrite, or simple element-by-element array operations that don't require BLAS or LAPACK functions could work on larger arrays.

Then we would also define something like fortran_integer_type for the Fortran-style function interfaces and check array sizes and limits when we actually call the Fortran-style functions.

Does anyone see a reason NOT to do this?

jwe

John,

This appears to be a significant improvement.
right now, I cannot think of anything that this would
break. Now that 64-bit is more common it makes sense to
make Octave "naturally" 64_bit. 32 bit may become a
special case...

Michael