Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <6956@mimsy.UUCP>
Date: Sun, 7-Jun-87 18:01:51 EDT
Article-I.D.: mimsy.6956
Posted: Sun Jun  7 18:01:51 1987
Date-Received: Sun, 7-Jun-87 23:46:13 EDT
References: <7619@brl-adm.ARPA> <958@killer.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

In article <958@killer.UUCP> jfh@killer.UUCP (John Haugh) writes:
>Assuming
>
>	int	fd;
>	struct	stat	stat1, stat2;
>
>	fd = open ("/dev/stdin", 0);
>
>do fstat (0, &stat1) and fstat (fd, &stat2) return the same thing?

Doing

	int fd = open("/dev/stdin", 0);

is supposed to be exactly equivalent to doing

	int fd = dup(0);

so the answer is `yes'.  More specifically, opening /dev/fd/n
returns whatever dup(n) would return.  The only tricky thing about
this is that the open mode (0, 1, 2) must match (or subset) the
mode of the existing descriptor `n'.  If file descriptor 4 is open
for reading only, and you attempt an open("/dev/fd/4", 1), the fd
driver should reject this (return -1 from open) because, due to
the dup-style implementation, writes on the new descriptor would
fail, just as they would if you had written

	int cc, fd = dup(4);
	...
	cc = write(fd, ...);

>What if _after_ the open I do a freopen (stdin, ...) or a close (0)
>followed by open (somefile)?

Everything works as if you had done a `dup(0)'.  `fd' still refers
to whatever was open before; 0 refers to whatever is open now.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris