Re: open undef shift

No explanation (yet), just an observation: strace shows Perl is creating temp files in all but the last case where the file name slot is $yund:

...
open("/tmp/PerlIO_Ol6dlF", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/tmp/PerlIO_Ol6dlF")            = 0
open("/tmp/PerlIO_WFvCgM", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/tmp/PerlIO_WFvCgM")            = 0
open("/tmp/PerlIO_su06bT", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/tmp/PerlIO_su06bT")            = 0
open("/tmp/PerlIO_HAAg8Z", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/tmp/PerlIO_HAAg8Z")            = 0
Use of uninitialized value in open at ./799021.pl line 32.
open("", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or 
+directory)
...
[download]

Probably some special handling when the file name is an explicit scalar variable as opposed to just an undefined value...

(This is generally documented:

    As a special case the 3-arg form with a read/write mode and the
    third argument being "undef":

        open(TMP, "+>", undef) or die ...

    opens a filehandle to an anonymous temporary file.
[download]

but it doesn't say anything about what happens if the undef isn't written literally...)

Comment on Re: open undef shift Select or Download Code

Replies are listed 'Best First'.
Re^2: open undef shift by ikegami (Patriarch) on Oct 03, 2009 at 18:01 UTC
No explanation (yet), You end up at one of these: `PerlIO * PerlIO_openn(pTHX_ const char layers, const char mode, int fd, int imode, int perm, PerlIO old, int narg, SV args) { if (narg) { if (narg > 1) { Perl_croak(aTHX_ "More than one argument to open"); } if (args == &PL_sv_undef) return PerlIO_tmpfile(); ...` [download] `PerlIO * PerlIO_openn(pTHX_ const char layers, const char mode, int fd, int imode, int perm, PerlIO f, int narg, SV args) { dVAR; if (!f && narg == 1 && args == &PL_sv_undef) { if ((f = PerlIO_tmpfile())) {` [download] Notice how they check if the file name SV is the global constant undef (`args == &PL_sv_undef`) rather than checking if it's undefined (`SvOK(args)`). It could be a bug, but I suspect it's intentional to try to detect the case where the file name is accidentally undef. It almost never makes no sense for a program to allow both a valid file name and undef. If your program is one of those, you can use `open(my $fh, '+>', $fn // undef)` [download] I think they should used a special character in the mode string instead of using a literal undef. but it doesn't say anything about what happens if the undef isn't written literally...) True, but one doesn't expect a difference in behaviour between the undefined value returned by `undef` and an undefined scalar. Any differences should be explicitly stated.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: open undef shift
by ikegami (Patriarch) on Oct 03, 2009 at 18:01 UTC

No explanation (yet),

You end up at one of these:

PerlIO *
PerlIO_openn(pTHX_ const char *layers, const char *mode, int fd,
             int imode, int perm, PerlIO *old, int narg, SV **args)
{
    if (narg) {
        if (narg > 1) {
            Perl_croak(aTHX_ "More than one argument to open");
        }
        if (*args == &PL_sv_undef)
            return PerlIO_tmpfile();
...
[download]

PerlIO *
PerlIO_openn(pTHX_ const char *layers, const char *mode, int fd,
             int imode, int perm, PerlIO *f, int narg, SV **args)
{
    dVAR;
    if (!f && narg == 1 && *args == &PL_sv_undef) {
        if ((f = PerlIO_tmpfile())) {
[download]

Notice how they check if the file name SV is the global constant undef (*args == &PL_sv_undef) rather than checking if it's undefined (SvOK(*args)).

It could be a bug, but I suspect it's intentional to try to detect the case where the file name is accidentally undef. It almost never makes no sense for a program to allow both a valid file name and undef. If your program is one of those, you can use

open(my $fh, '+>', $fn // undef)
[download]

I think they should used a special character in the mode string instead of using a literal undef.

but it doesn't say anything about what happens if the undef isn't written literally...)

True, but one doesn't expect a difference in behaviour between the undefined value returned by undef and an undefined scalar. Any differences should be explicitly stated.

[reply]
[d/l]
[select]