Re: File::Copy, autodie, VMS (was Re: maint-5.10-1531-ga5f97a6 on VMS status)

On Jul 7, 2009, at 3:24 PM, Craig Berry wrote:

> On Tuesday, July 07, 2009, at 11:03AM, "Paul Fenwick" <[email protected] 
> > wrote:
>> G'day Craig / All,
>>
>> Craig A. Berry wrote:
>>
>>> So likely we have an incompatible exit value on File::Copy, but I  
>>> don't
>>> know offhand why autodie cares about that.  Needs looking into.
>>
>>

>> However the documentation for File::Copy states for "RETURN":
>>
>>     All functions return 1 on success, 0 on failure.
>>
>> So it *should* be returning 0 if we're to be following what the  
>> docs say.
>>
>> I can patch autodie to skip this test on VMS,

Thanks, Paul.  That would be ok with me for 5.10.1, and I think would  
just mean adding a clause to the Windows skippage that's already there.

>> or we can patch File::Copy to
>> return 0 rather than "" on failure.  I believe that cherry-picking
>> 079cb8cc5abf40c0b016f9f878493b4d192d85d3 into maint-5.10 should do  
>> this.

I tested that and it solves the hints.t test failure on VMS, so that's  
option #2.

> Aha.  On VMS, File::Copy::syscopy is aliased to File::Copy::rmscopy,  
> which is implemented in XS at vms/vms.c:rmscopy_fromperl.  That's  
> been returning PL_sv_no on failure and PL_sv_yes on success since  
> the beginning of time, despite what the docs say.  Most likely  
> people have depended on simple truth value and it hasn't made much  
> difference.  But what I think needs doing is returning  
> sv_2mortal(newSViv(0)) on failure and sv_2mortal(newSViv(1)) on  
> success rather than the boolean brothers PL_sv_no and PL_sv_yes, but  
> I'm no XS guru and it may be a day or so before I have time to test  
> that theory.


Looks like that theory was good and I've pushed a change that does  
what I described earlier.  So option #3 is to take <http://perl5.git.perl.org/perl.git/commitdiff/fd18815 
 > for maint.  As far as I can think of, that could only cause trouble  
for someone who had empirically determined and depended on the  
incorrect behavior of returning false but non-zero on failure.  This  
change needs to go in eventually since rmscopy is documented as having  
0 and 1 return values independent of the syscopy documentation, but  
it's a very old bug and I don't have that strong a preference of how  
this gets settled for 5.10.1.

Dave, let us know if there's anything else you want to see to resolve  
this for 5.10.1.

________________________________________
Craig A. Berry
mailto:[email protected]

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