Re: Rethinking octave_idx_type

[Philip Nienhuis]

John W. Eaton wrote
> 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?

Would the current OF packages be affected?

Philip



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Rethinking-octave-idx-type-tp4680758p4680776.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.