[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'fstat' compatibility issue
From: |
Michael D. Godfrey |
Subject: |
Re: 'fstat' compatibility issue |
Date: |
Thu, 18 Feb 2010 21:48:09 -0800 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 |
On 2/18/10 7:18 AM, John W. Eaton wrote:
On 18-Feb-2010, Jaroslav Hajek wrote:
| In this particular case I think on Octave's part we can simply
| obsolete fstat and let the functionality be handled by "stat"
| directly.
| See the attached patch.
Seems OK to me.
Are there other functions that could or should be similarly merged?
The printf/fprintf functions come to mind, but I like having printf
available, so maybe we should keep it.
jwe
I use printf/fprintf often and, like others, find it a nuisance that
matlab lacks
them. I do not see any likely problem with the use of these names. Let's
keep them, please.
About the 64-bit issues, remember that the Unix filesystem, and all its
followers,
uses signed arithmetic for computing file addresses. That is why the
largest
file in 32-bit Unix is 2^31-2. I think it is true that the same
thinking was used for
"large" files. The largest file address allowed is, I think, 2^63-2.
Signed arithmetic
is required since offsets can be negative. (The minus 2 comes from the
fact that
the address of the next byte after the end of the file must be within
the address range.
This could have been done better.) Right now, no one can directly
handle 2^63 as
an address. The current processors have typically 42 address lines...
But it is not unreasonable
to think of a (very) sparse array with dimensions like 2^63. Virtual
address management
will need to become quite a bit smarter in coming years.
Michael