Thanks halley++.

That confirms my conclusions drawn from the limited discussion I could find on the matter at MSDN.

The problem I still have is that AS 802 is built for 32-bit integers but supports huge files...

perl58 -V
--- snip ---
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define usemultiplici
+ty=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
---snip---
[download]

As you can see, use64bitint and use64bitall are turned off, but uselargefiles is turned on. I can conform that 802 does handle files up to 10 GB.

The question comes, how? Given 32-bit "ambient integers", and no discernable other mechanism for indicating that fpos_t should be a 64-bit value, how does the compiler decide to switch to using a 64-bit fpos_t with fgtpos and fsetpos?

I guess it is possible that perl never uses fgetpos() and fsetpos() to satisfy calls to tell(), seek(), and stat(), and so the problem doesn't arise? I have to say though that from what I can make out from the sources, this is not the case. However, I'm not a compiler and trying to keep track of all the conditional compilation through myriad header files and source files is a job best left to a compiler:)

I guess it could be that fgetpos() and fsetpos() only ever get used by perl for its own file handling and not when doing IO on behalf of the user programs. This could mean that if I tried to run a perl script of > 4GB it might not be able to find the __DATA__ section.

Big deal:) I guess we'll cross that bridge when someone reports a problem with their 4 GB script. I just hope they remember to use <readmore> tags :)