Re: Cygwin's writev() non-standard behavior

2014-04-23 Thread qq qq
> I applied a patch to CVS. Thanks.  Although I could not see it in ViewVC -- the page stops loading at the "configure" script. Anyhow, I suppose that check_iovec still returns EINVAL for count==0 in any read functions:  simply returning "tot"==0 means EOF in many (if not all) of them. -- Prob

Re: Cygwin's writev() non-standard behavior

2014-04-23 Thread qq qq
> furthermore, cygwin should emulate Linux behavior, even if POSIX > doesn't define the behavior. And which is why I compared Linux vs. Cygwin in my original post ? > so your argument is flawed - you have triggered undefined behavior. Same difference: $ cat test.c #include #include #include #

Dup'd sockets lose error information

2014-04-23 Thread qq qq
The following code is a simplified app that was used to test-connect to local ports 55000+ (none of which were actually listening) and received false-positive "connected" results because Cygwin's dup() for socket causes SO_ERROR to be lost.  Since FD_SETSIZE is only 64 on Cygwin, the app uses du

Cygwin's writev() non-standard behavior

2014-04-23 Thread qq qq
writev() does not accept count 0 but it should $ cat test.c #include #include #include #include #include int main() {  struct iovec vec;  memset(&vec, 0, sizeof(vec));  if (writev(1, &vec, 0) < 0)    perror("writev");  return 0; } Linux: $ gcc -Wall test.c $ ./a.out Cygwin: $ gcc -Wa