Craig A. Berry wrote:
At 7:49 PM -0500 9/20/07, John E. Malmberg wrote:
Peter (Stig) Edwards wrote:
Content of
http://rt.cpan.org//Ticket/Display.html?id=29513
below:
Hello and thanks for maintaining PathTools.
The question/bug I have is:
"What should File::Spec->canonpath() return?"
On VMS (PathTools 3.17 and 3.25) I get undef:
perl -e "use strict;use warnings;use File::Spec;print defined
File::Spec->canonpath() ? 'def' : 'undef';"
undef
On UNIX (PathTools 3.23) I get empty string:
perl -e "use strict;use warnings;use File::Spec;print defined
File::Spec->canonpath() ? 'def' : 'undef';"
def
I would expect C<canonpath(undef)> to behave the same for both.
Agreed.
There is a problem on VMS if File::Spec->canonpath(undef) returns
'', as VMS will treat '' 'as SYS$DISK:[].;' which is likely to cause
>> hard to detect problems,
Uh, what? A return statement that looks like C<return '';> does not
return a string containing two single quote characters; it returns a
zero-length string. I must be missing what you're saying somehow.
Yes. What Peter is reporting is that File::Spec->canopath(undef) on VMS
currently returns C<undef>.
On UNIX it is returning C<''> or the zero length string.
A VMS file create of C<''> or a zero length string will succeed and
create a file with the name C<SYS$DISK[].;>, which is probably not desired.
So that is why I have the opinion that the current VMS behavior of
File::Spec->canonpath(undef) is more correct than the current UNIX
behavior, because it makes the error condition visible.
Having File::Spec->canonpath(undef) return C<undef> just seems logical,
and since both '' and undef will probably cause error conditions on UNIX.
-John
