Re: Perl / Win32 / VC++ / USE_LARGE

From Microsoft's Visual C++ 6.0's <stdio.h>, an excerpt posted for illustrative purposes according to fair use.

#ifndef _FPOS_T_DEFINED
#undef _FPOSOFF

#if defined (_POSIX_)
typedef long fpos_t;
#else /* _POSIX_ */

#if     !__STDC__ && _INTEGRAL_MAX_BITS >= 64
typedef __int64 fpos_t;
#define _FPOSOFF(fp) ((long)(fp))
#else
typedef struct fpos_t {
        unsigned int lopart;
        int          hipart;
        } fpos_t;
#define _FPOSOFF(fp) ((long)(fp).lopart)
#endif
#endif  /* _POSIX_ */

#define _FPOS_T_DEFINED
#endif
[download]

The fpos_t type's implementation chooses between three varieties, depending on ambient integer size options, where both non-POSIX varieties offer 64 bit signed lengths. I would check the command-line compiler switches to find any switch that controls (even indirectly) the integral word length.

--
[ e d @ h a l l e y . c c ]

Comment on Re: Perl / Win32 / VC++ / USE_LARGE_FILES Select or Download Code

Replies are listed 'Best First'.
Re: Re: Perl / Win32 / VC++ / USE_LARGE_FILES by BrowserUk (Patriarch) on Aug 26, 2003 at 18:56 UTC
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 :) 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.	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Perl / Win32 / VC++ / USE_LARGE_FILES
by BrowserUk (Patriarch) on Aug 26, 2003 at 18:56 UTC

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 :)

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.

[reply]
[d/l]