Re: [blead-498-gb94a8c4] vms chdir/chmod/mkdir... thread contextdependency removal

On Feb 7, 2009, at 1:06 AM, John Malmberg wrote:

> Craig A. Berry wrote:
>> On Feb 5, 2009, at 6:50 PM, John Malmberg wrote:
>>> Craig A. Berry wrote:
>
>>>> On Feb 4, 2009, at 8:43 AM, John Malmberg wrote:
>>>>
>>>>>
>>>>> +  ret = Perl_flex_lstat(NULL, file_spec, &st);
>>>>
>>>> You're explicitly passing a null thread context?  That won't work.

> I forgot that the thread context did not exist on non-threaded  
> builds when I put the NULLs in.

That's what the aTHX_ and pTHX_ macros are for.  I can't think of any  
reason you would ever explicitly pass a null thread context.

>>> as would remove the thread context from the wrappers and static   
>>> routines that do not need it.
>> If you're talking about routines prefixed with "Perl_" that's  
>> really  considered a public interface and shouldn't be changed on a  
>> whim.   Didn't you create some internal routines specifically for  
>> the cases  where we don't or can't use a thread context?
>
> Most of the wrapper routines for the CRTL do not need a thread  
> context anymore.  I can put that back.

I think we should leave the public-facing interfaces the same.   
Internal routines, on the other hand, (for example  
vms_rename_with_acl) can be changed if the change is an improvement.

>>> I will revise and resubmit with the changes to vmsish.h to remove   
>>> the thread context.  It will probably take a few days.
>
> Attached is the patch.

There seem to be at least three different things going on in this patch.

1.)  Removing thread context from the calling sequences of some  
routines.  I don't see that we gain a lot by doing this, particularly  
when there is an alternative routine without thread context available,  
and even if there's a compelling reason to do so we really shouldn't  
before 5.12 for the externally-visible routines.

2.)  A wrapper for fgetname to convert its result to Unix format when  
unix reporting is in effect.  Wouldn't it be easier to just define a  
macro like so:

#define fgetname(a,b) decc$fgetname(a,b,!decc_filename_unix_report)

?  Or when you said it's not working did you mean it is ignoring its  
optional third argument?

3.)  Some logic changes to the mkdir/chdir/chmod wrappers.  Those look  
fine offhand but are tangled up with #1 above.  Could I get them as a  
separate patch?

>

________________________________________
Craig A. Berry
mailto:[email protected]

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