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. > >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. >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. > > > >> >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. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
