[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: problem with string.format %d and very large integers
- From: Dimiter 'malkia' Stanev <malkia@...>
- Date: Wed, 17 Aug 2011 14:38:01 -0700
I knew about fileno, but I'm afraid if there is buffering involved,
filelengthi64() won't tell the whole story. Probabaly calling fflush()
before calling filelengthi64() might gives the right result (but then it
won't work at all for text files... not that it makes much sense to seek
in them). Also bit afraid of calling fileno() (I do it occasionally for
small "C" programs that I'm writing, but in general it breaks the
abstraction - hopefully MSVCRT.DLL on XP and on Vista have the same
structures involved - fileno just directly returns the FILE* structures
from the CRT).
For sure Microsoft messed up big time with this one, or some combination
of POSIX, ISO, ANSI misunderstanding...
I have the VS2005, 2008, 2010 CRT source code, (don't have the
MSVCRT.DLL one - maybe it shipped with VC6? - I have it somewhere and
might install it).
On 8/17/2011 1:16 PM, Thomas Lauer wrote:
Dimiter 'malkia' Stanev<firstname.lastname@example.org> wrote:
How do you handle the case where SEEK_END is used? I was looking for
function in this case to get me the file length in 64-bits, but could
not find any... (there is no ftello, that returns off_t, instead of long
which is 32-bit in my case).
I am currently far away from my developments machines, so I gotta rely
on memory and Google. There are two CRT functions involved, fileno() to
go from *FILE to file descriptor and _filelengthi64() which takes a file
descriptor and returns the file length. Something like this:
flen=_filelengthi64(fileno(fh)); // fh is a stream