damaki / ksum Goto Github PK

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

When ksum is run on Windows the expected behaviour of --text mode is that CRLF newlines are converted to LF newlines when reading input data. However, file data is always read in binary mode and CRLF are not converted, i.e. --text mode has the same behaviour as --binary on all systems.

After some investigation, this seems to be caused by using Ada.Text_IO.Text_Streams to read from the input files. Even when the file is opened with Form="text_translation=yes", stream reading always sets the file to binary mode before performing the read. See Ada RM A.12.2/6 which mentions mixing text/binary modes for text streams.