64bit foundation bug in Octave2.9.3

[John W. Eaton]

On 15-Jun-2005, Clinton Chee wrote:

| Version 2.9.3
| Platform: SGI Altix Itanium2 (linux)
| Compilers: Intel F/C/CC
| 
| 
| Dear All,
| 
| I was following up on Daniel's test of simple indexing to stress test
| the octave64 capability.
| 
| ccc(2^4)=0;
| 
| this should create a vector of 16 entries filled with zeros
| and it works!
| 
| ccc(2^32)=0;
| 
| this should create a vector of 4294967296 entries filled with zeros
| BUT it doesn't
| 
| After some investigation, I found:
| ccc(2^31) --> octave thinks it is ---> ccc(2147483648) CORRECT
| ccc(2^31+50) --> octave thinks it is ---> ccc( -2147483598) WRONG
| ccc(2^31+100) --> octave thinks it is ---> ccc( -2147483548) WRONG
| ccc(2^32) --> octave thinks it is ---> ccc(0) WRONG
| 
| In short, there's an error in the indexing which still seems to be "int"
| instead of the "octave_idx_type" index which I supposed to have change.
| 
| I tried tracing the bug but can't really nail it down. I can't find
| which class or function which I've missed changing the index. From the
| backtrace of a process that is actually giving the right result (eg,
| ccc(2^30) = 0; ), the following backtrace from gdb is obtained.

I did a liitle more checking on a 64-bit system with the latest CVS
sources and when I try

  x(2^32) = 0;

and break in

  Array<double>::resize_and_fill (octave_idx_type n, const double& val)

the value of N is 4294967296.  On the system I'm using, this
subsequently fails with an out of memory message, but I don't see that
anything is incorrect in the indexing.

jwe