Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: stat() in general (was read keyboard without stopping)
Keywords: curses keyboard
Message-ID: <13404@mimsy.UUCP>
Date: 6 Sep 88 15:32:44 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <690@super.ORG>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 58

In article <690@super.ORG> rminnich@super.ORG (Ronald G Minnich) writes:
>   I was not talking about tty devices, rather peter da silva's original
>comment questioning stat's not supporting the size field for ttys. 
>That comment got me to thinking about stat()s lack of generality, 
>since i had been burned by it once. I think that he was making the same point.

Ah.  Well, perhaps there should be several more stat fields, like
`distance to EOF if known', `number of bytes available without blocking',
and so forth.  (Note that the first two are not the same!  The subject
is `read keyboard without stopping' and I had been interpreting this
entire discussion from that viewpoint.  Please edit the subject line
when appropriate.)

(Incidentally, all the `on SysV' and `in SunOS 3.x' provisos I named
were intended as jabs at SunOS and SysV for botching generality.  Naturally
I consider 4BSD the One True Unix :-) and tend to ignore the others
when making statements about how `Unix' works.)

>>On regular files, you are at EOF if your current seek offset (available
>>via lseek()) matches the size returned via fstat().

>Only if someone else is not writing?

This is irrelevant.

>If you are reading a regular file, and someone else is writing, then
>there are times when your current seek offset will match the returned
>size. You are still not at eof, as someone else has the file open.

You are still at EOF.  That someone else has the file open is irrelevant.

>More data can come along. This is 'nothing available to read, but you
>are not at eof'.  I.e. tail -f, tail never really does know when it hits
>eof- you, peculiar creature that you are, decide for it via ^C :-).

But even if *no one* has the file open, someone can open it, append
data, and possibly close it again; then you are not at EOF anymore.
Any multiprocessing system without mandatory locks has this `feature'.
EOF is a fleeting concept.  You cannot pin it down save momentarily.

>P.S. Does it strike anyone as strange that stdio and level 2 have such
>different ideas about eof? Level 2 you can just read right through ^D; 
>As was pointed out, it is more like an enforced one-read FNDELAY than 
>anything else. for standard IO, one is enough; you lose it all right there. 
>The FILE * gets closed for you. 

False.  You must, however, call `clearerr' on the FILE pointer:

	...
	if ((c = getc(fp)) == EOF) {
		if (ferror(fp)) /* read error */ ...
		clearerr(fp); /* clobber EOF condition */
	} else {
		... process ...
	}
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris