Craig A. Berry wrote:
At 2:19 PM -0400 10/22/05, John E. Malmberg wrote:
my_chdir is a macro that will have an extra argument for interpreter
context in the case of building with threads enabled, but will be
identical to Perl_my_chdir for a non-threaded build. Here's what the
macro expansion looks like in the case of a thread-enabled build:
Ok, it sounds like I (and others?) need to work on a vmsinternals.pod to
remind me not to make the same mistakes over again, and hopefully help
others.
And that actually may help me with create a threaded rsync that is more
acceptable to the current maintainers.
- islnm = my_trnlnm(vmspath, esa, 0);
- trnend = islnm ? strlen(esa) - 1 : 0;
+ islnm = vmstrnenv(vmspath, esa, 0, fildev, 0);
+ trnend = islnm ? islnm - 1 : 0;
And these likewise?
This one's a little different. my_trnlnm is a macro that has the
interpreter context in the first argument for a threaded build, but
it was being called from within a function that did not have that
context. I have not done a full review to see if perhaps that
routine (one of your new ones that I forget the name of at the
moment) may need to have thread context passed to it, but the easiest
workaround in the meantime was to call a lower level routine that
does not have the extra parameter.
- entry = Perl_readdir(dd);
+ entry = readdir(dd);
*result = entry;
retval = ( *result == NULL ? errno : 0 );
This will probably break with the Posix Pathname mode. I think it
will need to call the CRTL readdir() routine from vms.c instead of the
>> replacement routines or that symbolic links will not be processed
>> correctly.
There should not in any case be a public routine in vms.c with the
>> same name as an existing CRTL routine of the same name.
There isn't. It's a macro.
If that still is the case then I missed an edit that I intended to make.
I will look at that again when I get back to merging in the symbolic
link support in and I have to make readdir() work with it.
As it is, there is a bug in readdir() handling and in the tests that is
exposed with EFS character set enabled.
The filenames returned by readdir() must be in UNIX format if the
argument to opendir() was in UNIX format, and in VMS format otherwise.
One of the perl tests expects that readdir is always returning a UNIX
file specification.
Unfortunately I have discovered that on some versions of the CRTL that
readdir() is broken and always returns the filename in VMS format.
The linker doesn't want them, not so much these macros as the
prototypes further down. They were getting in the symbol vector
option and causing link failures. Just stick them back in when they
actually point to something.
Interesting, I can not find any linker diagnostic information in my
build logs. I wonder why?
The main reason I put all that stuff into vmsish.h in advance is that
changes to it require a rebuild of the world, and I was trying to just
recompile vms.c for a bunch of incremental changes.
My next planned change is to simply to get rmsexpand() to handle long
filenames on input for 64 bit OpenVMS 7.2 and later and make sure that
it does not break anything.
Then it is to find all the places that need to deal with converted VMS
specifications internally to VMS.C and have them use rmsexpand() to do
the conversions. In the process of this, I should be able to migrate
8.2 and later to use the standard stat() routine.
Then finally to increase the buffer sizes in the routines for handling
filenames from Perl.
I am not sure how to make what will be the optional parameters for
rmsexpand to be visible from perl programs.
-John
[EMAIL PROTECTED]
Personal Opinion Only
