Re: [Mingw-w64-public] [patch] Add a bit of Cygwin winsock tolerance

[Corinna V. <vin...@re...>]

On Jun 28 16:06, Kai Tietz wrote:
> 2012/6/28 Ozkan Sezer <se...@gm...>:
> > On Thu, Jun 28, 2012 at 4:55 PM, Corinna Vinschen <vin...@re...> wrote:
> >> No worries.  Something else occured to me a couple of minutes ago.  The
> >> #ifndef FD_xxx guards don't make much sense right now.  After all, they
> >> are undef'ed anyway in winsock2.h since psdk_inc/_ws1_undef.h is
> >> included unconditionally.
> >>
> >> This means that any other set of FD_xxx macro definitions are
> >> overwritten with the winsock2.h version if winsock2.h is accidentally
> >> included after the other definitions of FD_xxx.
> >>
> >> That worries me a bit.  I can't lay my hand on an example yet, but it
> >> will probably show up sooner or later.
> >>
> >> So, here's my question.  What if the #undef of the FD_xxx macros in
> >> _ws1_undef.h are actually removed, as you proposed originally, and the
> >> entire mechanism is moved into _fd_types.h:
> >>
> >>    #if defined(FD_CLEAR) && defined(_FD_CLEAR_WINSOCK_DEFINED)
> >>    #undef FD_CLEAR
> >>    #endif /* FD_CLEAR && _FD_CLEAR_WINSOCK_DEFINED */
> >>    #ifndef FD_CLEAR
> >>    #define FD_CLEAR ...
> >>    #ifndef _WINSOCK2API_       /* Testing for _WINSOCKAPI_ isn't safe. */
> >>    #define _FD_CLEAR_WINSOCK_DEFINED
> >>    #endif /* !_WINSOCK2API_ */
> >>    #endif /* !FD_CLEAR */
> >>
> >> Alternatively we ignore the problem for now and wait calmly for a
> >> problem to show up.  What's your stance?
> >
> > Oh, I'm OK with with the above. Kai?
> >
> >>
> >>> (My only concerns were for the FD_* stuff. For the rest, others review
> >>> please.)
> >>
> >> Kai?
> >>
> >>
> >> Thanks,
> >> Corinna
> >>
> >
> > --
> > O.S.
> 
> Yes, I am fine by it, too.

Oops, did I misunderstand you?  I replied to your previous mail
discussing this further, because I was under the impression you would
prefer to stick to the current definition and the #undef in
_ws1_undef.h...


Corinna