[Octave-bug-tracker] [bug #58055] ftell() incorrect on MS Windows platforms if file is not encoded with CRLF line endings

[Rik]

Update of bug #58055 (project octave):

                  Status:               Need Info => Confirmed              
                 Summary: fgetl() reads in beyond newline according to
following ftell() => ftell() incorrect on MS Windows platforms if file is not
encoded with CRLF line endings

    _______________________________________________________

Follow-up Comment #11:

Thank you.  I think I see what is going on.

tst_58055_2 shows that it is not fseek which is the problem.  If the correct
offset is given then Octave positions the file pointer properly and fgetl()
works.

tst_58055_3 confirms that it is ftell() which is the problem.  The file
pointer should be at 52, but Octave returns 47.  There are 9 lines in the
file, but 4 of them have been read at this point.  That means there are 5 more
line endings, which apparently Octave believes are CRLF line endings because
it is on a Windows platform, so it is subtracting from the position the 5
extra CR characters that it *expects* must be there.

You can see this in the original example as well.  There are 27 lines in the
file, but 4 of them have already been read, so Octave believes there are
another 23 CR characters.  The file position, which should be 52, is therefore
reported as 52-23 = 29.

As a simple workaround for now, I would ensure that all *text* files you
create have the correct line endings for the platform you are working on.  If
you are passing files between Linux and Windows machines then you can use a
utility like dos2unix or unix2dos to convert back and forth.

Marking bug as confirmed.

Finally, I have yet another file tst_58055_4 that I hope you can run.  This
opens the file in binary, rather than text mode, and might make a difference. 
According to the documentation for fopen


Append a "t" to the mode string to open the file in text mode or a
"b" to open in binary mode.  On Windows systems, text mode reading
and writing automatically converts linefeeds to the appropriate
line end character for the system (carriage-return linefeed on
Windows).


Judging by that statement, Octave makes the choice about end-of-line
characters on a per operating system basis, rather than a per file basis.



(file #48794)
    _______________________________________________________

Additional Item Attachment:

File name: tst_58055_4.m                  Size:0 KB
    <https://savannah.gnu.org/file/tst_58055_4.m?file_id=48794>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58055>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/