There are several collisions between newlib and
winsock names These are the ones I know about.
1) The #ifndef _WINSOCK_H guard for BSD int typedefs
in the newlib sys/types needs to be made more specific
to prevent header inclusion order problems.
Consider what happens here:
winsock.h is included and defines _WINSOCK_H
winsock.h then includes >
which sees the _WINSOCK_H define and skips the BSD int
typedefs (u_char, u_short,etc) But ... sys/types
defines _SYS_TYPES_H which makes winsock.h also skip
the BSD typedefs later on. The types are not defined
2. fd_set. The same chain of included headers from
windows.h can also cause the wrong fd_set definitions
for winsock interface, but only in the case where
windows.h is included *before* winsock.h.
sys/types is included before winsock.h (ie before
_WINSOCK_H is defined),so the sys/types definitions
take precedence. One way to prevent the sys/types
definitions of fd_set is to use Win32_Winsock (or
similar macro thatsignifies intent to use winsock
interface), rather than _WINSOCK_H as a
3. gethostname. Both winsock.h and the newlib
sys/unistd.h declare gethostname. The w32api version
is __stdcall, the unistd.h one is not and also differs
in the second parameter (unsigned int rather than int).
IMO, if we want w32api for sockets, the function in
winsock.h/libwsock32.a should be used.
While I'm at I'd change the macro name Win32_Winsock
to something a bit more consistent with standard: eg
__USE_W32_SOCKETS_ but that is just my preference.
Mutually dependent patches to newlib and w32api,
against winsup cvs, follow.