Your answer proves that you exactly should bring this up on p5p rather than here :)

Of course it is not good that 5.8.1-pre do not compiles now with Borland C++ without touching source code tree (need some *.h patching), yet 5.8.0 builds with Borland fine -- no USE_LARGE_FILES, but source tree builds fine. Hence incompatibility was introduced somewhere in between. At least this needs immediate patches in p5p, may be you'll be in time before RC5 snapshot.
And 5.10.0-to-be also needs to be updated.

It is wrong to state that p5p is not aware of Borland compiler, it is really supported, but sometimes there is no Borland wisdom handy. You're very welcomed to add your efforts. Honestly.

I also must disagree with your "From Borland's perspective, the compiler is free and doesn't support huge files. If you want that then buy their professional compiler suite". Our department payed for professinal compiler suite, as of Borland C++ Builder 4, and it uses *exactly same compiler* as free compiler suite. If you buy commercial suite, you pay for IDE, VCL (another Borland CRT, but also lacking _*i64()). It has absolutely same and interchangeable compiler inside!

Now I'll do a humble attempt to answer your question, but don't expect much from stupid dog :)

You see many wrapper functions in ./win32/ sources. You don't even realize which of those are used and wrapped to what. The only I can say to you right now with probability of 99% is that fgetpos function from win32.c is *not* used, instead there is a forest of wrappers and ifdefs, and it is far from obvious what namely is called, look at occurences of fgetpos in miscellaneous files, especially this from perl.h:

#ifdef USE_64_BIT_STDIO
....
#   if defined(USE_FGETPOS64)
#       define fgetpos fgetpos64
#   endif

and

#ifdef USE_64_BIT_STDIO
#   ifdef HAS_FPOS64_T
#       undef Fpos_t
#       define Fpos_t fpos64_t
#   endif

yet in config_H.vc contains
#define Fpos_t fpos_t        /* File position type */
[download]

Anyhow, this becomes more and more complicated and I gave up when I looked into this last time, and I just beleived that "all works if API has 64 bit support and do not work otherwise".

However, still source code needs fixing to revive Borland build. The problem exists because many people propose patches into ./win32 files and they do not check Borland build, so they break it from time to time

And please do not mystify p5p and go discuss your thoughts there. You have your patches, so go and propose them.
Even I speak there. Hence anyone could speak there (provied there is something on-topic to say).
www.perl.com clearly suggests subscribing and discussing on p5p, so why not just go and do this?

Courage, the Cowardly Dog

Courage++ I think you have explained the fgetpos() fsetpos() connundrum.

As both calls are called with the address of the fpos_t parameter, if you pass the address of a 64-bit space to the function that only uses 32-bits of it, and then you pass that back to another function that only inspects the first 32-bits of it, then neither will care whether the space pointed at was 32-bits or 64-bits in size. Hence, that line from config_H.vc

#define Fpos_t fpos_t        /* File position type */
[download]

which as you say means that the underlying API will be called with a 64-bit chunck of memory regardless explains why it works.

Thanks :) You put that one to bed nicely and (hee hee!) now I don't have to bother p5p with a wild goose chase:)

As for submitting the patches, the only fly in the ointment there is that whilst I know which 3 files and 56 lines (all inserts) are effected, I am having trouble producing the patches in the form required by p5p. The diff utility I have (from The Unix in Perl project unfortunately cannot handle diff'ing the 5100 lines of win32.c. So it will have to wait until I find an alternative. Also, I need to (find where to) download bleedperl? and ensure that my patches are applied to that base rather then rc4.

RE: The Borland's professional CRT not supporting huge files. Frankly I am surpised and disappointed by this. Shame on them:)

Thanks for your help. It's good to know I am not the only one who finds the perl source codebase somewhat confusing:)

---

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.