Bob Friesenhahn wrote:
On Mon, 10 Nov 2003, Guido Draheim wrote:
That may be difficult to accomplish. I am not aware that Windows stdio and other high-level "Windows" I/O interfaces support large files since the APIs are 32 bit. You need to use _read, _write, _lseeki64, & _telli64 to support large files under Windows.
stdio does not care about off_t anyway, and that's what fseeko is for (AC_FUNC_FSEEKO). - And actually, the newer nt kernel is completely 64bit largefile inside and exports all the necessary API calls to let user applications work with largefiles. It's just not as easy as with the the posix "magic" define that we come to use through AC_SYS_LARGEFILE - you have to invent your own mappings to the win32 lfs transitional api which happens to be named slightly different than the posix lfs transitional api. see http://ac-archive.sf.net/largefile/win32.html for reference.
The stdio implementation and interface certainly depends on file offsets. My point is that stdio does not support 64-bit offsets under x86 Windows. This is in spite of NT and NTFS being able to support 64-bit offsets. The link you referenced seems to say the same thing as I did.
Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx http://www.simplesystems.org/users/bfriesen
Interesting hint, and there's more to it. Any application using the libc stdio api can not tell exactly whether it uses the 64bit largefile kernel api or not. It's generally unsafe to pick up a fileno() and chew on it with largefile calls - even that it is possible, the LFS summit pages have a few pages reserved for discussion on that but to me it sounds like they are unsure what effects might results. Same for the inverse of wrapping a largefile file-id via fdopen(). It's best to not mix it up.
For the unix systems however we may safely expect that unix vendor will ship along a libc implementation that takes advantage of 64bit fileoffsets of its kernel, so the fileno is really a largefile one. That lowers the number of problems in crossing over the api sides. http://www.opengroup.org/onlinepubs/007904975/functions/ftell.html describes how unix stdio implementations are asked to check the kernel fileoffset return value and make that an EOVERFLOW if the stdio return value would not be able to represent the real value.
With win32 systems that might be slightly different however since here the libc is not system-specific but compiler-specific. Each compiler vendor and compiler version may link its programs with a different libc implementation and it is uncertain whether that libc implementation takes advantage of kernel largefile calls. Actually, I just do not know but I expect that the most simple path has been used and the win32 stdio api is fully limited to 32bit on 32bit cpus, but that nay FUD and we better ask a guru.
cheers, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
