Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0
От | Bruce Momjian |
---|---|
Тема | Re: [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0 |
Дата | |
Msg-id | 20140401010149.GA6180@momjian.us обсуждение исходный текст |
Ответ на | [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0 (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: [BUG FIX] Compare returned value by socket() against
PGINVALID_SOCKET instead of < 0
|
Список | pgsql-hackers |
On Wed, Dec 25, 2013 at 01:35:15PM +0100, Joel Jacobson wrote: > Hi, > > I've tried to fix some bugs reported by Andrey Karpov in an article at > http://www.viva64.com/en/b/0227/ > > The value returned by socket() is unsigned on Windows and can thus not > be checked if less than zero to detect an error, instead > PGINVALID_SOCKET should be used, which is hard-coded to -1 on > non-windows platforms. I reviewed this patch and you are correct that we are not handling socket() and accept() returns properly on Windows. We were doing it properly in most place in the backend, but your patch fixes the remaining places: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740516%28v=vs.85%29.aspx However, libpq doesn't seem to be doing much to handle Windows properly in this area. I have adjusted libpq to map socket to -1, but the proper fix is to distribute pgsocket and PGINVALID_SOCKET checks throughout the libpq code. I am not sure how to handle PQsocket() --- should it still return -1? Having the return value be conditional on the operating system is ugly. How much of this should be backpatched? Why aren't we getting warnings on Windows about assigning the socket() return value to an integer? Updated patch attached. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-hackers по дате отправления: