How exactly to specify that FILE* is 64bit?

[DW7]

And I mean regardless if I define the application to be 32 or 64 bit?
Is it defined by the language (like in some header file) or the environment/target of development?
I intend to try it with VS 2013 on a Win 7 64 bit.
Thanks

[kbw]

Why do you care?

The (32bit) WIN32 API allows 64bit file access.

[DW7]

This is a reply to kbw:

If the FILE pointer is a 32 bit integer, that prevents my ability to create, save and process files larger than 2 GB and it has nothing to do with whether the OS is a 32 bit or 64 bit system.

[Disch]

I think you are confusing a FILE pointer with the internal pointer used by the file.

sizeof(FILE*) <- this value doesn't matter. This can be anything and it means absolutely nothing with regard to how big of a file you can read/write. This is what kbw is saying.


So it sounds like you are not asking about the FILE pointer, but rather are asking about how big of a file that the FILE api can access.

AFAIK, there is no guarantee that this will ever be larger than 32 bit. Which is why I simply don't use standard file I/O for projects where I want to deal with extremely large files. If you want to support big files you might want to consider looking at platform specific file i/o apis.

[Duthomhas]

What kbw is saying is this: No matter how you open a file on Windows, you have 64-bit file support. The intermediary library's API may limit you, such as with fseek() being limited to 32-bit seeks, but this isn't particularly opprobrious.

Check your compiler's documentation to see how to turn on LFS macros/etc, so you can code with the standard file functions but have them actually be the appropriate platform-specific LFS functions. You may get lucky.

Be aware that LFS is inherently non-portable.


And, IMHO, stupid. There aren't many good reasons to have such huge files, methinks.

[edit]
Wait a second, why is MiiNiPaa's post reported?

Please do not double post: http://www.cplusplus.com/forum/general/131880/

How wicked of him! Spam hater!

Oh wait! Report me too!

[vaportrack]

We don't need no stinking movie files or Terabyte drives.
What the world needs is more MS thinking on portability.
How else is one to rule the world?
Albeit this not much help, isn't NTFS 7 format a mix of a 32bit to 64bit extended attribute file name entry? Thus so what if it isn't? dang Im tired

[kbw]

dang Im tired

You must be, you used MS and portability in the same sentence.

[modoran]

It's not Microsoft fault, windows has full support for large files, it is compiler vendors which does not provide support in theirs CRT implementations.

Linux or Mac does not provide support for large files by default for ftell or fseek also, only for their own APIs, exactly like windows does.

So why blame Microsoft for that matter ?


ftell and fseek returns/want a long, so according to C standard a long is at least 32 bit in size. If it is something to blame then blame C standard itself.



AS for the title of this question, for windows and Visual Studio use _ftelli64 or _fseeki64 instead of standard and portable equivalents ftell and fseek or use win32 APIs directly if the compiler does not support these.