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()?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
