[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: synonym streams..
- To: ucbkim!Xerox.COM!Masinter.pa
- Subject: Re: synonym streams..
- From: franz!fizzy!jkf@kim.Berkeley.EDU
- Date: Mon, 18 Aug 86 15:22:59 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of 05 Aug 86 11:09:00 PDT. <860805-111034-2460@Xerox>
>> Date: 5 Aug 86 11:09 PDT
>> From: franz!ucbkim!Xerox.COM!Masinter.pa
>> I propose the following rule: "It is an error to attempt to close a
>> stream that wasn't created with open."
>> With this rule, it would follow that, since synonym, broadcast and
>> two-way streams are not created with open, it is an error to perform
>> "close" on them.
[sorry for the delay in the reply, this is the first chance I've had
This topic was brought up in this mailing list on Aug 21, 1985 and
discussed at great length on Sept 7, 1985. My feeling was then and
is still now that closing a synonym stream is legal, and that the only
effect is that read and writes to the closed synonym stream will cause an
error to be signaled. [At the time the only other possibility
discussed was that closing a synonym stream would cause the stream
that it was a synonym of to be closed as well. No one has brought
this option up so I assume that either it has no backers or else they
are on vacation].
Suppose I have a function which takes a stream and reads and
processes data from that stream and when an eof is seen, it closes the
stream and returns. What is to be gained by my program having to know
about synonym streams and having to check that it wasn't a synonym
stream passed in before it does a close? I would like my function to
be able to accept input from *standard-input* by having
my program create a synonym stream (call it X) for *standard-input*
and passing it to the function. When my function closes X, that should
be ok, and it shouldn't affect *standard-input* (or *terminal-io*,
if *standard-input* is a synonym for *terminal-io*).