Re: 'fstat' compatibility issue

[Michael D. Godfrey]

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