This is the mail archive of the
cygwin@sources.redhat.com
mailing list for the Cygwin project.
Bug when reading from a non-blocking pipe file descriptor, whilethe opposite end (the writing pipe file descriptor) is closed.
- To: cygwin at cygwin dot com
- Subject: Bug when reading from a non-blocking pipe file descriptor, whilethe opposite end (the writing pipe file descriptor) is closed.
- From: Anon Sricharoenchai <ans at beethoven dot cpe dot ku dot ac dot th>
- Date: Mon, 22 Jan 2001 00:10:58 +0700 (ICT)
The following is the C program to regenerate this bug.
#include <unistd.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
void test_func(int n1, int n2) {
int input_from_child[2];
pipe(input_from_child);
if (fork()) {
char buf[20];
close(input_from_child[1]);
fcntl(input_from_child[0], F_SETFL, O_NONBLOCK);
sleep(n1);
printf("%d\n", read(input_from_child[0], buf, sizeof(buf)));
} else {
close(input_from_child[0]);
dup2(input_from_child[1], 1);
close(input_from_child[1]);
sleep(n2);
exit(0);
};
};
int main() {
test_func(1, 0);
test_func(1, 2);
return 0;
};
When compile and run on linux, the output of running this program should
be as follow.
0
-1
But when compile and run using cygwin, the output will be as follow.
-1
-1
The latter case is a bug on cygwin. Because when calling
read(input_from_child[0], buf, sizeof(buf)) from test_func(1, 0), the
file descriptor input_from_child[0] should be in the end of file status
that should cause the read(...) to return 0.
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple