On Jun 28 16:25, Ozkan Sezer wrote:
> On Thu, Jun 28, 2012 at 4:16 PM, Corinna Vinschen <[email protected]> wrote:
> > On Jun 28 14:20, Ozkan Sezer wrote:
> >> - The patch moves the defs to a shared header but doesn't remove the
> >> associated #undefs from psdk_inc/_ws1_undef.h
> >
> > Hmm.  AFAICS they should stay there.  The _fd_type.h header is included
> > from winsock.h and winsock2.h only.  If you include winsock2.h before
> > winsock.h, the content of winsock.h will be ignored and you'll get the
> > FD_xxx definitions for winsock2.h.  If you include winsock2.h after
> > winsock.h, you want the FD_xxx definitions to be undef'ed, so that the
> > subsequent
> >
> >  #ifndef FD_xxx
> >  #define FD_xxx
> >  #endif
> >
> > will define the winsock2.h version of the definition, which seems to be
> > especially important for FD_SET.  Did I miss something?
> >
> 
> Ah, you are right: since _ws1_undef.h is included before _fd_type.h
> and the moved macros have ifdef guards, that should be fine, sorry.

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?

> (My only concerns were for the FD_* stuff. For the rest, others review
> please.)

Kai?


Thanks,
Corinna

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to