[Xcb] Win32 port - pls review

[Jeetu Golani]

>>#ifndef _WIN32 inside #if USE_POLL seems redundant. USE_POLL
>>shouldn't be defined on Win32.

>>Hmm Win32 doesn't have the poll function and uses WSAPoll instead so
>>we'll need to somehow #ifdef the poll function. Pls let me know alternate
>>mechanisms to achieve this.

I just realized that if USE_POLL isn't defined on Win32 then #ifndef _WIN32
is indeed
redundant. Will make the necessary change a little later in the day.

- Jeetu
http://www.ebrain.in
- An open (GPL) platform to discover and run software off someone in the
meshed network pool and use it on your own device.

twitter:  @0topcat0 and @ebrainpool




On Wed, Mar 31, 2010 at 10:06 AM, Jeetu Golani <jeetu.golani at gmail.com>wrote:

>
> Hi,
>
> >>You appear to have accidentally dropped a number of headers in
> >>xcb_util.c, including <fcntl.h> and <netinet/tcp.h>, so libxcb doesn't
> >>compile any more on *ix.
>
> Ouch...sorry have included them back in the code.
>
> >>#ifndef _WIN32 inside #if USE_POLL seems redundant. USE_POLL
> shouldn't be defined on Win32.
>
> Hmm Win32 doesn't have the poll function and uses WSAPoll instead so
> we'll need to somehow #ifdef the poll function. Pls let me know alternate
> mechanisms to achieve this.
>
> >>The do-while around select in xcb_in.c might not be required on Win32,
> >>but does it hurt?
>
> Win32 doesn't have the EINTR error code flag and uses WSAEINTR instead
> so we will have to #ifdef this region or change it somehow.
>
> Pls let me know what other changes need to be made here and any thoughts
> on the above.
>
> Bye for now
> Jeetu
> http://www.ebrain.in
> - An open (GPL) platform to discover and run software off someone in the
> meshed network pool and use it on your own device.
>
> twitter:  @0topcat0 and @ebrainpool
>
>
>
> On Wednesday 31 March 2010, Peter Harris wrote:
> > On 2010-03-30 15:32, Jeetu Golani wrote:
> > > I have updated the Win32 port to the current (few weeks old) tree of
> xcb.
> > > Have conducted a few rudimentary tests and it seems to perform all
> right.
> >
> > Looks good. I appear to be down to nits, none of which are critical as
> > far as I can see. Thanks for working on this.
> >
> > You appear to have accidentally dropped a number of headers in
> > xcb_util.c, including <fcntl.h> and <netinet/tcp.h>, so libxcb doesn't
> > compile any more on *ix.
> >
> > SOCKET on Win32 is currently defined to intptr_t, which is wider than
> > int on 64-bit systems. We can probably get away with leaving fd as an
> > int, for the sake of keeping the code at least somewhat sane. (Neither
> > breaking the ABI on *ix nor #ifdefing the type on Win32 are particularly
> > appealing, from what I can see). Note that Win32, unlike posix, does not
> > just allocate FDs one by one starting from stderr, so it's more likely
> > that some app will run in to this than a *ix person might think. But I
> > believe current implementations of Windows try to keep SOCKETs below
> the
> > 31-bit barrier most of the time.
> >
> > #ifndef _WIN32 inside #if USE_POLL seems redundant. USE_POLL
> shouldn't
> > be defined on Win32.
> >
> > The do-while around select in xcb_in.c might not be required on Win32,
> > but does it hurt? I'd rather avoid as many #ifdefs as possible. In the
> > same vein, Remi already suggested using send/recv everywhere (even on
> > *ix). What do you think?
> >
> > There's trailing whitespace in a few places. "git diff --color" to see
> >  them.
> >
> > _XCB_WINDEFS_H -- identifiers starting with underscore followed by
> > another underscore or a capital letter are reserved in C (7.1.3). I've
> > already lost this battle, as the rest of xcb already stomps on this
> > namespace, but I thought I'd point it out.
> >
> > What does the rest of the list think? Is it better to use a name that
> > resembles the rest of the names in XCB, or should we try to avoid the
> > reserved namespace going forward?
> >
> > Peter Harris
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100331/11795b97/attachment-0001.html>