in reply to Re: Why does fpathconf give "bad file descriptor"?
in thread Why does fpathconf give "bad file descriptor"?

Aha! That makes perfect sense now that you mention it. So strange that it's worked great all these years... what in the world is actually happening under the covers with that glob such that it works? It must be "usually" resolving to FD 0 or something like that.

  • Comment on Re^2: Why does fpathconf give "bad file descriptor"?

Replies are listed 'Best First'.
Re^3: Why does fpathconf give "bad file descriptor"?
by ikegami (Patriarch) on Mar 31, 2010 at 20:01 UTC
    Don't you use warnings?
    $ perl -MPOSIX -wle'print fpathconf(*STDOUT, _PC_PIPE_BUF)' Argument "*main::STDOUT" isn't numeric in subroutine entry at -e line +1. 4096 $ perl -MPOSIX -wle'print fpathconf(*FOO, _PC_PIPE_BUF)' Name "main::FOO" used only once: possible typo at -e line 1. Argument "*main::FOO" isn't numeric in subroutine entry at -e line 1. 4096

    And yes, they are being interpreted as zero.

    $ perl -wle'print 0+*STDOUT' Argument "*main::STDOUT" isn't numeric in addition (+) at -e line 1. 0 $ perl -wle'print 0+*FOO' Name "main::FOO" used only once: possible typo at -e line 1. Argument "*main::FOO" isn't numeric in addition (+) at -e line 1. 0
      His original code gives no warnings. And 0 + $wd doesn't evaluate to 0. I think it evaluates to the address of the object.

      Looking at the code for fpathconf in glibc, I see that, for 16 of the 21 configuration parameters, fd is ignored—except to check that it is >= 0. So I think what's happening is that when the objects are being allocated above (void *)((unsigned int)-1 >> 1), when it's passed as an int, it's negative, so it gives an error.

        Ah! He said glob in Re^2, but he's actually passing a ref to a glob in the OP (which becomes a number with no warning).