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

[John W. Eaton]

Follow-up Comment #17, bug #58055 (project octave):

It does seem that _ftelli64 is incorrectly adjusting for CRLF -> LF
translation, but we shouldn't need to know the real offset, whatever it is. 
The docs for _fseeki64 say this:


For streams opened in text mode, fseek and _fseeki64 have limited use, because
carriage return-line feed translations can cause fseek and _fseeki64 to
produce unexpected results. The only fseek and _fseeki64 operations guaranteed
to work on streams opened in text mode are:

  * Seeking with an offset of 0 relative to any of the origin values.

  * Seeking from the beginning of the file with an offset value returned from
a call to ftell when using fseek or _ftelli64 when using _fseeki64.


So using a value returned from _ftelli64 with SEEK_SET should return you to
the position in the file that was previously saved and I think that's all the
original report was about and all that my test program was trying to do.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fseek-fseeki64?view=vs-2019

Internally, I don't think Octave ever opens files using text mode (for reading
.m files, for example).

So this problem may be limited to the stream classes defined in
oct-stream.{h,cc} and related files that are used to support C-style file I/O
in the interpreter.  Maybe we can avoid this problem by having Octave's stream
objects note that a file is open in text mode but actually use binary mode
internally, and then perform the CRLF->LF translation as needed?  I believe
this translation would be limited to Windows systems because on Unixy systems,
there should be no difference between text and binary mode.



    _______________________________________________________

Reply to this item at:

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

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