Re: win32 socket definition - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: win32 socket definition
Date
Msg-id 9837222c1001061337n23a89bcfi2aa1feb07cf36ad7@mail.gmail.com
Whole thread Raw
In response to Re: win32 socket definition  (Magnus Hagander <magnus@hagander.net>)
Responses Re: win32 socket definition  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: win32 socket definition  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 1, 2010 at 20:55, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, Jan 1, 2010 at 20:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> The win64 port has showed that we have two sockets declared
>>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>>> they are declared as int. See attached patch.
>>
>>> Given that SOCKET is actually defined as int on win32 (no warnings or
>>> anything there, just on win64), I'm inclined to apply this patch just
>>> to HEAD and not bother with backpatching.
>>
>> This looks pretty bletcherous --- plastering #ifdef WIN32 all over the
>> code is exactly not the way to be fixing this sort of thing.  Maybe we
>> should go the other direction of "typedef int SOCKET" on Unix then use
>> SOCKET everywhere.
>
> Yeah, we can do that - I figured since it was only two places, this
> was easier...
>
> In keeping with how we usually name things though, shouldn't it be
> pg_socket, and then have it typdef'ed to two different things
> depending on which platform you're on?

Something along the line of this?

Is there a good trick to find out if you've touched every place you
need to, because I'm very unsure I have. I don't even get a warning in
more than those two places, but there ought to be some way to trick
the system to tell me?


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: unresolved bugs
Next
From: Joachim Wieland
Date:
Subject: Re: Cancelling idle in transaction state