ksum doesn't read past SUB control characters (Windows)

[damaki]

On Windows, if the file contains SUB control characters 16#1A#, then ksum reaches end-of-file at these bytes. This affects both text and binary modes, although the behaviour is slightly different between the two. In text mode, ksum doesn't read past the first SUB byte. In binary mode, the first read from the file is OK, but the second read will fail in the same way - stopping at the next SUB byte.

This bug does not occur on Linux, so far it has only been encountered on Windows (and not tested on Mac).

After some debugging this seems to be caused by using End_Of_File to determine the end of the file stream. This makes sense since SUB can be used to signal the end of file in text files, and Text_IO is used. An alternative approach could be to use the number of bytes read from the stream as the loop exit condition instead of End_Of_File. E.g. exit when 0 bytes are read.

The version of GNAT I used was GNAT Community 2019 20190517 for Windows x64