On Thu, Jun 28, 2012 at 4:55 PM, Corinna Vinschen <vinsc...@redhat.com> wrote: > On Jun 28 16:25, Ozkan Sezer wrote: >> On Thu, Jun 28, 2012 at 4:16 PM, Corinna Vinschen <vinsc...@redhat.com> >> 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?
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. ------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
