Front page | perl.perl5.porters |
Postings from December 2013
On Wed Dec 18 15:59:59 2013, tonyc wrote: > On Thu Jul 11 21:27:20 2013, xyf.xiao@gmail.com wrote: > > Thanks all to reply ! it seems a OS specific issue, The test script > > works fine in both windos and linux platform. I'll do some dig at > > this > > weekend to find the underlying reason. > > It looks like the bug is cygwin (or maybe a limitation of Win32) > doesn't update the socklen parameter supplied to recvfrom(), so if you > supply a large buffer (as perl does, since it needs to allow for non- > IPv4 protocols like UNIX sockets), the whole buffer is returned, not > just the struct sockaddr_in part. > > As to whether this is a Win32 limitation - the Win32 documentation for > both recvfrom() [1] and WSARecvFrom() [2] both indicate that the > from/fromlen parameters are ignored for connection oriented sockets. Thinking about it some more, I wonder if the definition and implementation of recv()s return value is simply broken. From my reading, POSIX[1] makes no guarantees about the value of *I<address_len> (or the memory addressed by I<address>) when reading from a socket: If the address argument is not a null pointer and the protocol does not provide the source address of messages, the value stored in the object pointed to by address is unspecified. Both Linux, OS/X and OpenBSD (and probably others) happen to set *address_len to 0, but I don't see that behaviour specified anywhere. An implementation might ignore address and *address_len instead, as Win32[2] and cygwin both do. All that said, I might just workaround this in the same way as win32_recvfrom() does - call getpeername() if the output address_len is the same as the input. Tony [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvfrom.html [2] we workaround this --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=118843Thread Next