Re: segmentation fault when load more then 2.1 GB

[Daniel Heiserer]

> | Why not changing ftell/fseek etc. to ftello/fseeko?
> | http://www.ece.utexas.edu/~luo/linux_lfs.html
> | then 64bit large files support can be enabled during compile time.
>
> That could allow you to read large files, but what will you do with
> the data once you have read it?  Octave does not currently support
> arrays larger than 2GB on systems that have 32-bit ints.  Or are you
> saying that the file is larger than 8GB, but it contains no individual
> matrix objects that are larger than about 2GB?

At least one object is larger then 2GB. I submitted a patch on February 
12th 2003 which fixes that problem. I never got a feedback concerning 
the question for the "adverse effects" also I haven't seen the patch 
included till today. Unfortunately the people answering the thread 
focused on the bad timing of the "rand" function I used to demonstrate 
the usage :-(

The patch was:
http://www.octave.org/octave-lists/ archive/bug-octave.2003/msg00306.html

I am willing to help fixing all this "size" limitations quickly. The 
main reason why this stuff didn't bother most people up to now was 
simply that it takes a reasonable investment in hardware to deal with 
large problems (more then 2GB memory and a 64 bit OS).
However dawn has approached for these restrictions. It will be only a 
question of time when this limitation will become a major problem for 
many people.
The reason that "the leading competitior" might have a problem with it 
as well is for me not the reason of not fixing it.


-- daniel