@mmuetzel, I am happy to work on it, but I am not familiar with the overall code structure of octave. I will need some pointers where to start.

can you let me know what unit I should be looking at that is most relevant to this fscanf behavior?

When I was testing a toolbox I wrote on windows yesterday, I realized that this issue goes back to even older versions on Windows, including 7.3 and 6.4.

Specifically, fscanf(fid, '%f', [4, inf]) fails to parse any line ending with -1 1 in the below testing file on Windows

fid=fopen('testdata.txt', 'rt');
data=fscanf(fid, '%f', [4, inf])';
fclose(fid);

20  3  0  0
   0    1  1  1
   1    1  1  -1
   2    1  -1  1
   3    1  -1  -1
   4    -1  1  1
   5    -1  1  -1
   6    -1  -1  1
   7    -1  -1  -1
   8    1  0  1
   9    0  1  1
  10    0  -1  -1
  11    1  -1  0
  12    -1  0  -1
  13    -1  -1  0
  14    0  1  -1
  15    1  0  -1
  16    1  1  0
  17    -1  1  0
  18    -1  0  1
  19    0  -1  1

this should be a high-priority bug and deserves immediate attention and fix

fscanf is such a frequently used function and it is broken on windows.


I just noticed this bug when my github testing script failed on windows

https://github.com/fangq/iso2mesh/actions/runs/11396953367/job/31711637777

after debugging this problem, I found the culprit was fscanf failing to read the data file. Here is a very simple test

create testdata.txt with the following content

3 5088 5089 4737
3 4336 8 7
3 2922 6 5

then run

fid=fopen('testdata.txt','rt');
elem=fscanf(fid, '%f', [4 3])'
fclose(fid)

the output looks like

elem =

      3   5088   5089   4737
      3   4336      8      3
   2922      6      0      0

basically, everytime when there are two single-digit number at the end of the line, the second number will be dropped. I saw this pattern in a larger file as well.

Tested on windows 10 with Octave 9.2. I also have octave 8.x/7.x/5.x installed on this system, and none of them had this problem. Must be introduced in the 9.x version.

This seems to depend on CRLF line endings. If I convert the files to LF line endings, all tests pass...
Alternatively,  if the files are opened in binary mode, all tests also pass with CRLF line endings.

Windows does some weird things with the file position when the line endings are converted on-the-fly in text mode. Maybe, the issue is somewhere around that.

For the time being opening the files in binary mode seems to be a work-around. I.e., `fid = fopen(fname, "rb");` or simply `fid = fopen(fname, "r");`.


You marked this as a regression. Do you know in which version of Octave this was still working?