[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: CLOSED-STREAM-OPERATIONS (version 3)
- To: vanroggen%aitg.DEC@decwrl.dec.com
- Subject: Issue: CLOSED-STREAM-OPERATIONS (version 3)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 17 Oct 88 15:11 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8810131858.AA13409@decwrl.dec.com>
Date: Thu, 13 Oct 88 11:58:56 PDT
Clarify that one may call the following functions on closed streams without
error due to the stream being closed:
This is not the same as saying they will continue to return the same values.
- perhaps CLOSE on a closed stream should return NIL, not T.
- perhaps some implementations would want INPUT-STREAM-P of closed streams to be NIL.
i think there's no good reason to have that be so, but it's an issue that would
have to be resolved and implementations would likely diverge in the absence of info
so it could lead to portability troubles if we don't clarify that if a stream was
INPUT-STREAM-P when open, it will be when closed, too. [we might acknowledge the
possibilty that a stream could be `re-opened' in an implementation-specific way,
in which case the way this function operated could change.]
(SETQ S (OPEN "file" :DIRECTION :INPUT))
(INPUT-STREAM-P S) => T
(CLOSE S) => T
(CLOSE S) => T ;NIL?
(INPUT-STREAM-P S) => T
(OPEN S :DIRECTION :OUTPUT) => ??
(INPUT-STREAM-P S) => ??
- I could imagine the pathname information for a pathname wanting to change from
the opened name to the truename upon close. eg, if you open .NEWEST, you might
know the truename only after you close. TRUENAME might therefore want to return
something different after CLOSE. Whether it should be permitted is something
-we- should decide, not something we should leave up to implementors ... at least
not without making it explicit that we're doing so.
- Gack. I never noticed that PATHNAME-VERSION could be called on a stream. Hmmmm.
Same comment as for TRUENAME, I guess.
- The interaction of DIRECTORY is particularly interesting. Even if the truename
does not change, some file systems will treat DIRECTORY of foo.lisp.newest
differently depending on whether the stream to that file is still open. Some can
tell you the file is there but it's still open, while others will not admit its
existence until it's closed. I don't think we can get away without saying
something about this.
Any operation for which the level of well-definedness of its meaning is not preserved
by CLOSE is at least a candidate for making an out-and-out error since the behavior
after CLOSE will not be portably defined. Actually, we can probably say "unspecified"
in most cases rather than "undefined" since we can say the behavior is harmless, but
it just may not be particularly meaningful...