This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Cygwin c++ vs windows or unix socket layer



    Hi all,

  I've stumbled across a small problem.

  As you may know, cygwin attempts to give the user a free choice of using the
winsock API, with SOCKETs being handles not fds, and ioctlsocket and
closesocket and so on, or using the posix sockets API, and having sockets
being fds just like any other file, using the same ioctl and close functions,
etc. etc.

  This doesn't work well in C++ at the moment, because of a clash between
headers; winsock defines gethostname to take an int as the second argument,
while cygwin's unistd.h defines it as taking an unsigned int.

  Normally the solution to this would be to only use one or the other kind of
socket library and not attempt to mix the two in one program.  Unfortunately,
if you include any of the C++ i/o stream related headers, that includes
c++io.h, which includes gthr.h and hence gthr-default.h; and gthr-default.h
unconditionally #includes <unistd.h>.  (Note that gthr-posix.h could cause the
same problem, if you've explicitly requested posix threads by defining
_GLIBCXX__PTHREADS).

  So the upshot is that if you use C++ i/o streams you get unistd.h included
and that defines the posix version of gethostname and then you can't include
(or use) the winsock stuff instead; i.e. cygwin's c++ compiler does not
currently support allowing the choice of socket library.  There's no problem
in C, because you're not forced to include the gthreads headers to support
standard library functions; it's just that the C++ i/o classes need to know
about mutex functionality in order to be threadsafe.

  A patch like this makes it work for me, and I was wondering if anyone else
has had this problem and if I should include it in the next release of cygwin
gcc when it comes out.  According to the svn logs, the reason
gthr-default/posix.h needs to include unistd is solely to get the feature test
macros; although posix expects them to be available /through/ unistd.h I think
we're still ok by having it as a separate subinclude file and that does give
us the advantage of being able to pull them in without all the hundreds and
thousands of random unrelated stuff that the full unistd.h has.

  I've Cc'd the gcc list because, although this is primarily a cygwin issue,
and an artifact of the way we try to support two clashing environments,

a) someone might know some more important reason why gthr-default really does
need the unistd function prototypes, or
b) others might also feel that implicitly including unistd.h and thus pulling
in a bunch of network/socket related symbols into every C++ io stream-related
header file is a bit overly namespace-polluting.
c) something else, that I haven't thought of  :)



--- gthr-default.h      2006-05-26 16:59:57.917146100 +0100
+++ gthr-default.h.new  2006-05-26 17:00:26.307771100 +0100
@@ -41,7 +41,11 @@ Software Foundation, 59 Temple Place - S
 #endif

 #include <pthread.h>
+#ifdef __CYGWIN__
+#include <features.h>
+#else
 #include <unistd.h>
+#endif

 typedef pthread_key_t __gthread_key_t;
 typedef pthread_once_t __gthread_once_t;
dk@rainbow /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin/bits>



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]