Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!iuvax!pur-ee!a.cs.uiuc.edu!uxc.cso.uiuc.edu!urbsdc!willcox
From: willcox@urbsdc.Urbana.Gould.COM
Newsgroups: comp.bugs.4bsd
Subject: Re: fcntl does not perform as stated in
Message-ID: <28300009@urbsdc>
Date: 21 Jul 88 13:58:00 GMT
References: <405@oravax.UUCP>
Lines: 29
Nf-ID: #R:oravax.UUCP:405:urbsdc:28300009:000:1133
Nf-From: urbsdc.Urbana.Gould.COM!willcox    Jul 21 08:58:00 1988


>What this call does is to make sure that any *future* read call will
>return -1 with errno set to EWOULDBLOCK.  The fcntl call itself just
>specifies that this is the specified behavior, rather than the normal
>behavior of blocking until input is available.  The return value of 0
>indicates that the fcntl completed successfully, rather than (in this
>case) EBADF stating that you passed it an invalid file descriptor (d).

This isn't how I read the original note, though it was a bit ambiguous.  

The fcntl (...FNDELAY) ensures that a later read on the file descriptor
will set EWOULDBLOCK if it would block.  This does not apply to regular
files, just to things that might block you for a long time like ttys or
sockets.

The original posting expected the later read to return -1 and set
EWOULDBLOCK on an EOF, but FNDELAY does not change the behavior of a
read at EOF.

David A. Willcox
Gould CSD-Urbana
1101 E. University Ave.
Urbana, IL 61801
217-384-8500
UUCP: uunet!uiucuxc!urbsdc!willcox
ARPA:	willcox@xenurus.Gould.COM
	willcox@Gould.COM
	willcox@gswd-vms.Gould.COM (old host name)
	willcox@gswd-vms.arpa (old host name)