[Openmcl-devel] File-length bug?

[Pascal J. Bourguignon]

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. 

man lseek:

       The  lseek() function allows the file offset to be set beyond the
       end of the file (but this does not change the size of the file).
       If data is later written at this point, subsequent reads of the
       data in the gap (a "hole") return null bytes ('\0') until data is
       actually written into the gap.


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


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?

I agree that we lack a good POSIX oriented CL implementation.  You know,
an implementation where iolib, etc, would be "native", where physical
pathname namestrings would be POSIX paths, etc.


On the other hand, I'm not sure current implementations need to evolve
toward such a goal.  (It is not necessary for conforming programs).  For
example, in the case of ccl, I'm rather happy that it keeps historical
features going back as far as MCL on MacOS, working on porting a MCL
application to MacOSX as I am now…  I'm rather dreaming of a new
implementation.  But since we don't have the resources, I guess nudging
an implementation toward POSIX might be easier.



(In any case, a conforming program wouldn't call file-position with
random integers.)


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin