On 5/25/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
Charles E Campbell Jr wrote:
> A.J.Mechelynck wrote:
>
>> I'm not sure what varnumber_T means: will st.stsize (the dividend) be
>> wide enough to avoid losing bits on the left?
>
> varnumber_T is int (long if an sizeof(int) <= 3).
>
> st.stsize 's size depends on whether 32bit or 64bit integers are available.
>
> So, its possible to lose bits: pick a small enough unitsize and a large
> enough file, st.stsize will end up not being able
> to fit into a varnumber_T. After all, unitsize could be 1, and
> getfsize() will behave no differently than it does now.
> However, unitsize could be 1000000. My patch divides st.stsize by the
> unitsize first; presumably in whatever
> arithmetic is appropriate for working with st.stsize.
>
> Regards,
> Chip Campbell
>
Yes, yes, but before the division, will it be able to hold the file size?
(sorry, I meant st.st_size) Will mch_stat (at line 10134, one line before the
context of your patch) be able to return "huge" file sizes?
stat() on Linux has 32-bit st_size field (off_t is 32-bit). There is stat64()
syscall which uses 'struct stat64' structure where st_size is 64-bit. By
defining __USE_LARGEFILE64 at compile-time, stat() is redirected to
stat64(). I don't know whether default Linux vim build defines
__USE_LARGEFILE64 or not.
Yakov
