octave_idx_type vs mwSize, mwIndex, and mwSignedIndex

[John W. Eaton]

In Octave, we currently declare both array sizes and indices with
octave_idx_tyep, which is normally defined to be int, or, if compiling
with --enable-64, it is whatever type is required to get a 64-bit
signed integer.

Looking at the Matlab docs, it has

  mwSize:        normally int, or, with large array dimensions, size_t
  mwIndex:       normally int, or, with large array dimensions, size_t
  mwSignedIndex: normally int, or, with large array dimensions, ptrdiff_t

Does anyone else think it would be good for us to also have a size
type in addition to an index type?

Do we actually need a signed index type?  What is it used for?

Even if we do not decide to use both size and index types and use
only octave_idx_type, then should we just define it to be size_t?

The reason we are using a signed integer now is so that it matches the
signed integer values in Fortran 77 (which has no unsigned types).
But I don't think there is any harm in passing an object of size_t
(which should be an unsigned 64-bit value on a system with 64-bit
pointers) to a function that expects an INTEGER*8 value, unless the
value passed is larger than 2^63 or less than 0.  An array dimension
or index that is greater than 2^63 is probably not useful for a system
like Octave (or pretty much any actual system today, as that is one
gigantic number of array elements).

Currently when building Octave with --enable-64, we compile all the
Fortran bits with an option like gfortran's -fdefault-integer-8 switch
that makes all INTEGER values 8-bytes wide.  For values that are array
dimensions or indices, 8-bytes makes sense, but there are other values
that are passed as option flags or error indicators that don't really
need to be 8 bytes wide.  So it would probably be better to not have
the Fortran code use 8-byte values for all integer values, but fixing
that correctly would probably be a lot of work.

There are also other cases where blindly using 8-byte values cause
some real trouble.  For example, the algorithms used in ranlib and
also the {S,D}LARUV random number generators in LAPACK apparently
assume that the integers they are working with are 32-bits wide and
will not work properly if they are not.  So compiling a correctly
functioning version of the reference LAPACK that uses large array
dimensions is not quite as simple as just setting an option like
-fdefault-integer-8.

Comments?

jwe