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.