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