[Openmcl-devel] File-length bug?

Ron Garret ron at flownet.com
Sun Aug 4 03:01:55 UTC 2013


On Aug 3, 2013, at 5:53 PM, Pascal J. Bourguignon wrote:

> Ron Garret <ron at flownet.com> writes:
> 
>> Leaving aside the question of whether or not it is possible to tail a
>> file in portable CL (I don't actually care about portability, which is
>> why I'm asking this question here rather than on CLL), it seems to me
>> that (> (file-position f) (file-length f)) should never be true.
> 
> There's nothing that prevents it, on POSIX systems.  You can seek way
> beyond the end of file, and write some data there.  That makes sparse
> files.

Yes, I know.  But the invariant that file-position<=file-length is nonetheless maintained:

? (open #P"~/Desktop/foo" :direction :output :if-does-not-exist :create)
#<BASIC-FILE-CHARACTER-OUTPUT-STREAM ("/Users/ron/Desktop/foo"/21 UTF-8) #x302002D7DFBD>
? (setf f *)
#<BASIC-FILE-CHARACTER-OUTPUT-STREAM ("/Users/ron/Desktop/foo"/21 UTF-8) #x302002D5D1AD>
? (file-position f 100)
100
? (file-length f)
100

>> Just for the record, SBCL does this:
>> CLisp does this:
> 
> Since you've not used as argument to file-position a value returned by
> file-position, or :start or :end, you're in implementation dependant
> territory.

Yes, I know.  That's why I posed my question on openmcl-devel rather than comp.lang.lisp.

> So again, the question is what expectations you want the implementations
> to provide for, in their implementation dependant features.  Be closer
> to the underlying POSIX system?  Be more consistent in a general way?
> Be compatible with more other implementations?

Personally, I don't really care.  All that matters to me is that I get it to work.  Right now my fallback plan is to use run-external-program to invoke tail -f, but it seems to me there ought to be a better way.

> I agree that we lack a good POSIX oriented CL implementation.

I dunno, I think CCL is a splendid POSIX implementation (and actually SBCL and CLisp don't suck too badly either).  It works for me 99.9% of the time, and the remaining 0.1% the Clozure folks always handle the situation in one of two ways: either they agree that there's a bug and they fix it, or they point out why it's not a bug and how the problem should be solved instead.  I am quite confident that one of those two things will happen as soon as gb gets around to reading this thread.

rg




More information about the Openmcl-devel mailing list