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

I think you should:
$sz = fpathconf(fileno($wd), _PC_PIPE_BUF)
        or die "fpathconf(pipe): $!\n";

[download]
From what I see in POSIX.xs, the conversion of a Perl file handle to a file descriptor is not done for you.

Replies are listed 'Best First'.
Re^2: Why does fpathconf give "bad file descriptor"?
by madscientist (Novice) on Mar 31, 2010 at 19:34 UTC

    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.

[reply]
      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

      [download]

      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

      [download]
[reply]
[d/l]
[select]
        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.

[reply]

In Section Seekers of Perl Wisdom