Sorry, Rick, I did indeed mean READ-LINE. This is very easy to reproduce.

Create a "DOS" file with two lines of 10 characters each:

File: in.dat
1234567890
abcdefghij

This file will be 24 bytes long.

( Open the file with ) s" in.dat" r/o open-file . value fid
( Read a line ) pad 10 fid read-line . . . ( prints 0 -1 10 which is right )
( Where are we ) fid file-position . d. ( prints 0 12 - that 12 s/b 10 )
( Read rest of line ) pad 10 fid read-line . . . ( prints 0 -1 10 )

That last print, with a standard conforming read-line should be ( 0 -1 0 ).
SwiftForth is actually reading the second line.

Bill

Monday, February 10, 2003 11:54 AM, you wrote

RV> Do you mean READ-LINE instead of READ-FILE ? There have been no
RV> fixes to either in quite a long time. Please provide an example
RV> of the failure, including a datafile to reproduce it with, to
RV> help_at_forth.com
>
RV> Monday, February 10, 2003, 8:20:23 AM, you wrote:
>
>BM> READ-FILE, a standard word, fails when the number of characters
>BM> requested equals the number of characters on a line in the file
>BM> (not counting the EOL characters). As documented in the source
>BM> code, the file pointer should be positioned at the beginning of
>BM> the EOL. The bug is that the file is actually getting positioned
>BM> AFTER the EOL characters.
>
>BM> Has there been a fix posted that I missed?

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe sftalk" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/sftalk -- check them out!
Search the archives! Visit http://www.forth.com/search for details.
Received on Mon Feb 10 2003 - 09:20:51 PST