[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)
    Message-id: SU-IMSSS.REM.A132116072744.G0366
    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)
    Reply-to: REM@MIT-MC.ARPA

    > 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
interface chapter.

    > 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.