Re: [Sbcl-devel] :if-exists :append behavior (was Re: Issues in OPEN, FILE-STREAMs, et al.)

[Richard M K. <kr...@pr...>]

Rudi Schlatte writes:
> On 20.02.2008, at 09:57, Richard M Kreuter wrote:

> > That's true, they're not.  And ISTM that it would be better to not
> > use O_APPEND, for various reasons I mention in my writeup.
> >
> 
> FWIW, I'd argue that our current behaviour for:
> 
> * (with-open-file (s "/tmp/foo.txt" :direction :output :if- 
> exists :supersede) (write-string "xxxxxxxx" s))
> 
> * (with-open-file (s "/tmp/foo.txt" :direction :output :if- 
> exists :append) (file-position s :start) (write-char #\a s))
> 
> is a bug -- namely, the file contents end up being "xxxxxxxxa", not  
> "axxxxxxx".

The problem with reasoning about the conformance of an OPEN
implementation is that the standard lets an implementation deviate from
the the details of OPEN:

| The various file systems in existence today have widely differing
| capabilities, and some aspects of the file system are beyond the scope
| of this specification to define.  A given implementation might not be
| able to support all of these options in exactly the manner stated.  An
| implementation is required to recognize all of these option keywords
| and to try to do something "reasonable" in the context of the host
| file system.  Where necessary to accomodate the file system, an
| implementation deviate slightly from the semantics specified here
| without being disqualified for consideration as a conforming
| implementation.  If it is utterly impossible for an implementation to
| handle some option in a manner similar to what is specified here, it
| may simply signal an error.

So we can, in effect, adopt the policy that using O_APPEND is not a bug,
but an implementation-specific deviation, if we want to retain our
definition of :APPEND.

(Please note that I'm not trying to play devil's advocate; I'm just
reporting all the issues I think relevant: conformance in on a detail
that's explicitly murky, upward compatibility with ourselves,
compatibility with other Lisps, etc.)

> > (a) since we're permitted to deviate from the specification in the  
> > CLHS, and
> 
> I confess I'm not sure what you mean by that --

I was referring to the CLHS section above.

> > (b) if we want to retain compatibility with the current :APPEND
> >     semantics in FD-STREAMs,
> >
> > then we should keep O_APPEND there.
> 
> In summary, I think we simply have a bug here -- and one that iirc got  
> corrected in Paul Foley's simple-streams impl (and perhaps also in the  
> main cmucl sources, not sure) after I reported it to him.  I was lax  
> and too inexperienced to check and correct sbcl's fd-stream behavior;  
> I'm sorry I didn't fix this when I was doing work in that area.

Well, we can fix it now, if people are agreed.

--
Richard