Someone reported an issue on XL mailing list about the following code in fe-connect.c failing on Power PC platform:
1844 if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
1845 (char *) &optval, &optlen) == -1)
1846 {
1847 appendPQExpBuffer(&conn->errorMessage,
1848 libpq_gettext("could not get socket error status: %s\n"),
1849 SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
1850 goto error_return;
1851 }
1852 else if (optval != 0)
1853 {
1854 /*
1855 * When using a nonblocking connect, we will typically see
1856 * connect failures at this point, so provide a friendly
1857 * error message.
1858 */
1859 connectFailureMessage(conn, optval);
1860 pqDropConnection(conn);
1861
1862 /*
1863 * If more addresses remain, keep trying, just as in the
1864 * case where connect() returned failure immediately.
1865 */
1866 if (conn->addr_cur->ai_next != NULL)
1867 {
1868 conn->addr_cur = conn->addr_cur->ai_next;
1869 conn->status = CONNECTION_NEEDED;
1870 goto keep_going;
1871 }
1872 goto error_return;
1873 }
TBH the reported failure is in another component of XC code which is borrowed/copied from the above portion. So it could very well be XC specific issue. But the reporter claims that initialising optval to 0 where its declared or commenting out "else if" part fixes his problem. I found that strange because the preceding getsockopt() should have initialised optval anyways.
Can some kind of compiler optimisation reorder things such that the "else if" expression is evaluated using the old, uninitialised value of optval? Or these branches are evaluated sequentially so there is no chance that the "else if" expression would not see the new value of optval set by getsockopt()?
