At 2:19 PM -0400 10/22/05, John E. Malmberg wrote:
>Craig A. Berry wrote:
>>Change 25824 by [EMAIL PROTECTED] on 2005/10/22 16:43:40
>>
>>      VMS threaded build fixes for things broken in #25783
>>-          if (eqv && *eqv) Perl_my_chdir(eqv);
>>+          if (eqv && *eqv) my_chdir(eqv);
>
>So I do not break things again, can you explain to me what the difference 
>between these two definitions are?

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:

      4  100056           if (eqv && *eqv) my_chdir(eqv);
       E                                   Perl_my_chdir(my_perl, eqv)

>
>>-       mp_do_pathify_dirspec(name, remove_name, 0);
>>+       do_pathify_dirspec(name, remove_name, 0);
>
>>-       mp_do_pathify_dirspec(name, remove_name, 0);
>>+       do_pathify_dirspec(name, remove_name, 0);
>
>>-    else retval = mp_do_kill_file(dirfile, 1);
>>+    else retval = mp_do_kill_file(aTHX_ dirfile, 1);

Same macro situation as above.

>
>>-     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.

>
>And unless I got the previous change wrong, readdir() is should now be calling 
>the real CRTL readdir().
>
>>==== //depot/perl/vms/vmsish.h#73 (text) ====
>>Index: perl/vms/vmsish.h
>>--- perl/vms/vmsish.h#72~25801~       Tue Oct 18 17:29:00 2005
>>+++ perl/vms/vmsish.h Sat Oct 22 09:43:40 2005
>>@@ -234,14 +234,6 @@
>> #define init_os_extras               Perl_init_os_extras
>> #define vms_realpath(a, b)   Perl_vms_realpath(aTHX_ a,b)
>> #define vms_case_tolerant(a) Perl_vms_case_tolerant(a)
>>-#define vms_decc_feature_get_name(a) \
>>-                     Perl_vms_decc_feature_get_name(aTHX_ a)
>>-#define vms_decc_feature_get_value(a, b) \
>>-                     Perl_vms_decc_feature_get_value(aTHX_ a, b)
>>-#define vms_decc_feature_set_value(a, b, c) \
>>-                     Perl_vms_decc_feature_set_value(aTHX_ a, b, c)
>>-#define vms_decc_feature_get_index(a) \
>>-                     Perl_vms_decc_feature_get_index(aTHX_ a)
>
>So you do not want these in until the real functions are implemented?
>

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.
-- 
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to