I've just come to the end of doing some sockets programming using cegcc, and I thought some experiences might be useful to others.
If you use blocking sockets, then things seem to work OK as far as I could tell using the newlib POSIX layer. But then, blocking sockets are not very exciting, and I wanted to use non-blocking sockets, which opens up more potential for weird behaviour. The first thing to note was that (the same as winsock) you really need to wait until the connection is complete before trying to do any send()'s or recv()'s. The reason (I think, from memory) is that if you rush to using send/recv after initiating the connection, then the error message you get when the socket is still connecting is indistinguishable from that you get when the socket has disconnected in error (ENOTCONN). On linux, for example, you get EAGAIN in this circumstance, which means you can get away with some simpler code in some circumstances. I'm not sure what the behaviour is on other POSIX systems, or what it is meant to be. The real showstopper to using "newlib sockets", though, was that the whole application would rudely exit if the connection was closed at the other end, and then you called send() on the socket. I wondered if this was due to send() ignoring MSG_NOSIGNAL, generating a SIGPIPE, and that the uncaught signal was causing a program exit. I did try writing a signal handler, which all compiled OK, but did not change the behaviour (and no evidence that the signal handler was called). I ran the application from the MSVC debugger and saw a "Data Abort" in the debugging window when the program exit occurred. I wonder if I had written my application as main program rather than a DLL (which is used in a MSVC program) then there would have been some initialisation that would have made things work? I didn't try this. I don't even know if signals are supported by the cegcc version of newlib either. So I had no luck with newlib sockets. Fortunately, you can access the winsock sockets easily enough by putting "#define __USE_W32_SOCKETS" in your code (and including winsock2.h instead of all the unix stuff, and using WSAStartUp, WSACleanup and WSAGetLastError, and changing all the error codes to WSA ones, etc). This time there were no unexpected program exits and everything seemed to work ok. That is until the WiFi driver on my iPAQ decides to throw a wobbily, unloads the driver, only to be restored by a system reset! (anyone know about the reliability of WiFi on a HP iPAQ 27xx?). Works fine over the USB, though. Hywel. Danny Backx wrote: > On Tue, 2008-06-17 at 08:54 +0100, Hywel B. Richards wrote: > >> Do you really need to call WSAStartup when you are using cegcc (of the >> non-mingw variety)? >> >> Wouldn't the POSIX compatibility provided by newlib do this for you? >> > > Hmm, apparently it does. I didn't know that. > > Does anyone know how good this stuff > (src/newlib/newlib/libc/sys/wince/msnet.c) is at hiding the differences > between winsock and unix sockets ? > > Danny > > >> I ask with interest as I also want to do some networking stuff soon. I >> was assuming that if I used cegcc-mingw then I would need WSAStartup, >> but not if I used the non-mingw version. >> >> Hywel. >> >> >> Danny Backx wrote: >> >>> I believe you need to call WSAStartup before any winsock call. That's a >>> difference between sockets on Unix (Linux, ..) and on Windows. >>> >>> Danny >>> >>> >>> ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
