If you process binary files, you won't get far reading it line by line. You want to read chunks of data. 4tH can do that too by using 'ACCEPT'. You feel there must be a catch, since 'ACCEPT' terminates strings automatically. Well, there isn't. When 'ACCEPT' does not read from the keyboard, it won't add that extra byte.
Reading blocks of data usually means defining buffers. If maintainabil- ity is an issue, define a constant for the sizes of these buffers. You cannot only use this constants when defining buffers, but also when calling 'ACCEPT'.
Furthermore, 'ACCEPT' returns the number of characters actually read. If this value is compared to the number of characters we actually wanted to read, we can determine whether a reading error or EOF occured:
1024 constant bufsize \ actual buffersize bufsize string buffer \ define buffer 64 string filename \ define string " infile.dat" filename copy \ make filename input open if \ open input file input file \ redirect input begin \ using bufsize bufsize ( n1) buffer over ( n1 a n1) accept ( n1 n2) <> ( f) \ make EOF flag until \ until EOF else \ issue error message ." File could not be opened" cr quit then
Note that "BUFFER" is actually not a string, but a chunk of memory. But since a character in 4tH takes up a single address-unit (=byte), raw chunks of memory are allocated in the Character Segment. This is not an uncommon practice in both Forth and C.