[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What should CLOSE return?
Date: 3 April 1985 03:29 est
From: Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)
Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:00 PST (=GMT-8hr)
Date: 1985 April 02 18:50:35 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
Subject:attempt to bind constant, what should CLOSE return
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
> Date: Thu, 21 Mar 85 00:49 EST
> From: Nick Gall <Gall@MIT-MULTICS.ARPA>
> From: Robert Elton Maas <REM@IMSSS.SU.EDU>
> Subject: What should CLOSE return? Closed-channel-object, or truefilename.
> > !topic What does CLOSE Return?
> > I think it should return the STREAM it was given to close. This
> > would make it symmetric with OPEN: OPEN returns an open stream,
> > CLOSE returns a closed stream.
> That's not symmetric, that's coercive. OPEN and CLOSE are like
> matching parenthesis, one does it and the other undos it except for
> a residual side-effect. ...
> You're right `symmetric' is the wrong adj. But I still think CLOSE should
> return the (closed) stream. It can't (always) return the truename
> of the file associated with the stream, since not all streams are
> associated with files.
It's a matter of opinion as to what "should" be returned, and if
there's any use for the closed stream that couldn't be obtained by
retaining a pointer to the original open stream and using that pointer
after the CLOSE has been done, then I'll agree with you. But usually a
closed stream is just an open stream that has been modified in place
to be closed, in which case anyone wanting the closed stream can just
as well retain the old pointer instead of expecting that CLOSE will
return it back to you. On the other hand, if a system doesn't assign a
version number until the moment a file is closed, and if there's no
particular reason to need CLOSE to return the closed stream, then it
should return the true filename to save the user the hassle of getting
that info itself.
You still haven't said what close should return when the stream being
closed is NOT a file stream (e.g., closing a string stream). Note that
the CLOSE function is in the chapter on streams NOT the file system
> To obtain the truename of a just closed file, one could write
> (truename (close x)) ; where x is bound to a file stream
> since truename will take a stream as an argument. (Unfortunately,
> the CLRM (23.1.2(5)) is only explicit about what truename does
> with an `open' stream.)
Clearly something needs to be change, either force truename to work on
closed streams, telling the true name that couldn't have been known
for sure while the file was still open, or having CLOSE return the
true filename as I suggested.