Bug #52323 [Fbk->NoF]: php_network_connect_socket doesn't return all errors correctly

Edit report at https://bugs.php.net/bug.php?id=52323&edit=1 ID: 52323 Updated by: php-bugs@lists.php.net Reported by: onno at flox dot org Summary: php_network_connect_socket doesn't return all errors correctly -Status: Feedback +Status: No Feedback Type: Bug Package: Sockets related PHP Version: trunk-SVN-2010-07-12 (SVN) Assigned To: pajoye New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: ------------------------------------------------------------------------ [2010-09-08 13:51:13] pajoye@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=303172 Log: - fix the fix for bug #52323 ------------------------------------------------------------------------ [2010-09-08 12:33:57] pajoye@php.net The error part of the patch has been applied to 5.3 and trunk. I think the rest of this issue is fixed as well. However I would like to hear from you to be sure that what we've done fix the problem for your cases as well (just to be sure). ------------------------------------------------------------------------ [2010-09-08 12:25:42] pajoye@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=303166 Log: - Fix bug #52323, return value of php_network_connect_socket should be set even if the caller does not care about the error_string ------------------------------------------------------------------------ [2010-09-07 13:19:02] cataphract@php.net +1 for the first half of the patch. It doesn't make sense that the return value varies according to whether the caller is interested in the error string or not... ------------------------------------------------------------------------ [2010-09-07 12:46:14] cataphract@php.net I think it makes moresense leave php_poll2 untouched. See http://linux.die.net/man/2/poll, which is being emulated and http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx which is being used for the implementation. The patch in this bug report fills the exceptfds if POLLERR is given, instead of POLLPRI. However, POLLERR is supposed to be output only as per poll(2)'s specification. This way, * PHP_POLLREADABLE can be given to check if there's data to be read -- although, like the comment in php_poll2 says, it can also mean POLLHUP and POLLERR. Since we "can't know this without probing", we default to retuning POLLIN. * POLLOUT can be given to check if data can be sent/will not block. In windows, it can also mean a nonblocking connection was successful. We can't distinguish between the two, so we return POLLOUT. * POLLPRI can be given to check if processing a connect call (nonblocking), connection attempt failed or OOB data is available for reading (only if SO_OOBINLINE is disabled). Again, we can't distinguish between the two, so we return POLLPRI. It has to be caller that disambiguates the return value. In Windows, in case of a nonblocking connect call, we should pass POLLOUT|POLLPRI. When read the return, we know that POLLOUT means the connection was successful and POLLPRI means the connection failed (see patch for bug #50953). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52323 -- Edit this bug report at https://bugs.php.net/bug.php?id=52323&edit=1