in reply to Re^3: open undef
in thread open undef

I am not really sure if I understand what you are trying to say (but it is very interesting) - so thanks for that.

For me I am trying to figure out why perl handles the cases differently.

My position is that what happens in the first case is the proper thing to do.

You want to open a file for reading and you supply undef as a file-name: Error. That's how I think it should be.

And I still cannot quite see why the cases supplied should be different.

And there is this: 

perl -MDevel::Peek -e'Dump($ARGV[0])'
SV = NULL(0x0) at 0x55a8c4978560
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)

perl -MDevel::Peek -e'Dump(undef)'
SV = NULL(0x0) at 0x55923aa70560
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)

[download]
Both have the same high refcount, but the addresses seem to differ - why is that?

Is this a can of worms that one should not open?

Replies are listed 'Best First'.
Re^5: open undef
by ikegami (Patriarch) on Aug 02, 2018 at 20:24 UTC

    My position is that what happens in the first case is the proper thing to do.

    The first and third case are behaving correctly. The middle one should behave like the first, but open can't tell the difference between an unallocated array element and undef (since they both return the undef).

    the addresses seem to differ - why is that?

    I believe memory addresses are varied between program runs to minimize the damage from certain types of attacks. If you did both Dump in the same run, they would have the same address. 

    $ perl -MDevel::Peek -e'Dump($ARGV[0]); Dump(undef);'
SV = NULL(0x0) at 0xf78148
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)
SV = NULL(0x0) at 0xf78148
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)

$ perl -MDevel::Peek -e'Dump($ARGV[0]); Dump(undef);'
SV = NULL(0x0) at 0xbe6148
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)
SV = NULL(0x0) at 0xbe6148
  REFCNT = 2147483639
  FLAGS = (READONLY,PROTECT)

    [download]
[reply]
[d/l]
[select]
      Ah ok, that makes sense.

      As for the behaviour in the middle case I must say that I consider that to be bug. Your explanation makes sense, but it is a bug nevertheless - would you agree?

[reply]

        Yes, it's a known bug.

[reply]
      ForgotPasswordAgain quoted the applicable documentation. Based on this quote, I would expect all three cases to create the temporary file. I agree that only the third case should. The quoted specification should be changed to reflect this.
      Bill
[reply]

        The documentation says that using "undef" (not "an undefined value") creates the temporary file, but the first two cases don't use undef. As such, according to the documentation, only the third case should create the temporary file.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom