Is this code safe?

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Is this code safe?
Дата
Msg-id CABOikdM+9uG6Z3AyM6K-EWXYAJPSrEiCWRkLVeeiqnXuH67YHA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Is this code safe?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Dense index?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is this code safe?