Is it normal for a call to getpeername(2) on a non-socket
(a pipe, more specifically) not to return any error? This
behaviour is causing trouble with FastCGI, and is contrary
to about all other OS' around?

  Given the following perl snippet:

--- cut here ---
laubach1:15 [~] % cat testsock
use Socket;

socket SOCKET, AF_UNIX, SOCK_STREAM, PF_UNSPEC;

undef $!;
getpeername(SOCKET);
print "getpeername(sock) $!\n";
  
pipe READ, WRITE;

undef $!;
getpeername(WRITE);
print "getpeername(write) $!\n";
  
undef $!;
getpeername(READ);
print "getpeername(read) $!\n";
--- cut here ---

  This returns on NetBSD:

| laubach1:16 [~] % perl testsock
| getpeername(sock) Socket is not connected
| getpeername(write) 
| getpeername(read) 

  While it does

| > perl testsock
| getpeername(sock) Socket is not connected
| getpeername(write) Socket operation on non-socket
| getpeername(read) Socket operation on non-socket
| > uname -s -r
| FreeBSD 3.2-RELEASE

| sun1% perl testsock
| getpeername(sock) Transport endpoint is not connected
| getpeername(write) Socket operation on non-socket
| getpeername(read) Socket operation on non-socket
| sun1% uname -a
| SunOS sun1 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-250

| www1:1 [~] % perl testsock
| getpeername(sock) A socket must be already connected.
| getpeername(write) The specified file descriptor is not a socket.
| getpeername(read) The specified file descriptor is not a socket.
| www1:2 [~] % uname -a
| AIX www1 3 4 00D3500C4C00

| # perl testsock
| getpeername(sock) Transport endpoint is not connected
| getpeername(write) Socket operation on non-socket
| getpeername(read) Socket operation on non-socket
| # uname -a
| SINIX-N sbi1 5.43 C3002 RM400 1/512 R10000

  Any comments? A bug on NetBSD?

	mjl