|Pathologically Eclectic Rubbish Lister|
Perl / Win32 / VC++ / USE_LARGE_FILESby BrowserUk (Pope)
|on Aug 26, 2003 at 10:33 UTC||Need Help??|
BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:
In the process of patching Win32.c and Win32sck.c to allow me to build perl using Borland C (the runtime of which doesn't support files >4 GB) with USE_LARGE_FILES and USE_PERLIO enabled, I noticed that there are numerous calls to the C-runtime routines fgetpos() and fsetpos(). These routines use a typedef fpos_t to get and set the file pointer position. The problem is that in the normal way of things, fpos_t is a 32-bit value. Obviously, when USE_LARGE_FILES is in effect, this requires a 64-bit value. I've coded a solution to bypass this for Borland, by going directly to the OS using SetFilePointer() and that works fine.
The problem is, when I was looking through the sources looking to see how these two calls where handled for VC++, and failed to find anything that specified that they should use a 64-bit value. The VC++ runtime docs suggest that fpos_t can use a 64-bit value "depending upon the target platform", but I've been unable to work out how this change is effected.
So my question is, how does perl get away with using fgetpos() and fsetpos() on huge files when there is no apparent code to indicate that a 64-bit value should be used? Does the VC++ C-runtime decide to switch to using an fpos_t that is 64-bits automagically? If so, upon what criteria? If not, is this a hole in the Win32/VC++ USE_LARGE_FILE support?
If anyone has an answer to any of these questions, or has a way of checking whether these calls work correctly when used by a perl built using VC++ and USE_LARGE_FILES, I'd be very grateful for their wisdom or assistance. Thanks.
BTW. If anyone else is interested in building perl for Win32 using Borland (a free compiler) send me a message. The required patches are minimal only 3 files are effected.
I'll probably submit a patch for this, but there is no telling how long it might be before it shows up in the build tree, always assuming that it is accepted. Testing so far is fairly minimal, but 99.77% of the test suite passes and the failing tests are unrelated to the modifications that I have made. I'm still trying to track down the causes and would appreciate some help if anyone is interested.
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.