Craig A. Berry wrote:
At 8:10 PM -0500 9/25/07, John E. Malmberg wrote:

Craig A. Berry wrote:

As far as I can tell, every other platform that has _LARGEFILE
support now makes it the default.  It seems to me we should too.  Any
reason not to?

I vote yes on the versions of VMS that support it.

And also to make _USE_STD_STAT the default on the versions that support it.

I wish that symlinks where in better shape, but they still need some work.


Sounds good.  As I think you know, _USE_STD_STAT will automatically
be enabled if large fie support is enabled.  We may want to
conditionalize that a bit more because I think there are systems that
support large files but do not support the standard stat.

The CRTL makes a distinction because there are programs that depend on the older incorrect behavior of stat() returning in st_dev a pointer to a string containing the device name. And of course since it was pointing to a static area that is overwritten with each call to stat, unless they made a copy, the information was easily lost or incorrect.

Since Perl has always hidden that issue, and generated a numeric st_dev, the major difference between using standard stat and the traditional stat is the number put in the st_dev.

The difference will probably only be noticed with mount points and symbolic links, as the old Perl algorithm is not able to correctly calculate the st_dev member in those cases.

I think you get the correct 64 bit st_ino when you select largefiles.

So when symbolic links are enabled, they should require the _USE_STD_STAT.

Now that brings up a question about binary compatibility because the difference in value returned in the st_dev depending on the build option.

So there may be another option to put in the list in perl.h.

So there may be a need to build a perl on with out using _USE_STD_STAT so that the st_dev member is compatible with a dynamically loaded module that was built on an earlier version of the OS.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Reply via email to