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

Reply via email to