Craig A. Berry wrote:
At 12:36 PM -0600 2/1/05, John E. Malmberg wrote:
On Mon, 31 Jan 2005, Craig Berry wrote:
I believe 64-bit integers and large file support now work correctly
(and independently) in bleadperl and those changes should make it
into 5.8.7.
I do not have bleadperl, but they are not in a snapshot of 5.9.1 I
downloaded a few days ago. I just put them in my local copy of 5.8.6,
but have not had time to test them.
Unfortunately you did not implement the not very well documented but
present lstat() routine which is about to start returning something
different than stat().
It looks like I need to copy how stat() was done for lstat().
I'm quite sure that we don't check for all routines that are now
supported and documented in the CRTL, so it doesn't surprise me that
something unknown outside of OVMS Engineering would not be tested for
in configure.com. It should be a simple addition, though, to test
for lstat() in configure.com. Is it available on all 8.2 systems, or
will it only appear later? It is not in the version dependency
tables or anywhere else in the brand new CRTL manual dated January
2005.
I will have to check to find out why lstat() is missing from the
documentation where it should be. It is referenced in the documentation
as a cross reference to a related feature.
I am not sure how long lstat() has been present in the CRTL, until
symbolic links start working, it should return the same as stat().
Also affecting this is now with 64 bit OpenVMS 8.2, there is a new
struct stat that is incompatible with either struct mystat flavor in perl.
It also removes most of the hacks that perl was doing to fill out the
mystat structure.
I believe the original hack was because existing code would compare
st_ino members of the stat structure to see if two files are the
same. Since the old VMS stat structure made st_ino an array of
words, only the first word would be compared, which was insufficient
for determining equality. So if we can do away with that in 8.2 and
later and simply make mystat an alias for stat, I'm all for it.
As it is unlikely that this will be backported, the old method will need
to be conditionally compiled.
A number of code porting projects suffered from the problems that you
described. I have a TPU macro that does a search and replace on the
inode assigns and compares, which changes them to memcpy and memcmp.
With 8.2, the ino_t is a 64 bit integral value, so number assigns and
compares will work.
With 8.2, the dev_t value will also be valid when you use the standard
stat variant, so that hack disappears.
But I notice that perl allows the script to choose local time or UTC for
what stat() outputs, so some of the wrapper will still be needed.
If largefile support is to be present, then the resulting config.h needs
to have a #define _LARGEFILE 1 in it.
I think I tried that, but that's too late. The CRTL headers that need to
see _LARGEFILE get included before config.h, so it had to be added on the
command line via /DEFINE=_LARGEFILE.
Why not just #include config.h before including the other headers?
It does not appear to do any harm to including it twice at a quick glance.
Because config.h is included from perl.h, and perl.h must be included
after either EXTERN.h for modules that reference globals, or
INTERN.h, for modules that define globals. Even if changing the
order appears to work now, there is no telling what dependencies
might show up based on current documented order of inclusion.
I noticed that this seems to be done on other platform variants.
-John
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Personal Opinion Only
