bugGNU Octave - Bugs: bug #58055, ftell() incorrect on MS Windows...

 
 

bug #58055: ftell() incorrect on MS Windows platforms if file is not encoded with CRLF line endings

Submitter:  Toby <streumix>
Submitted:  Fri 27 Mar 2020 09:07:22 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.2.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 16 Apr 2020 12:09:47 PM UTC, comment #23: 

That sounds reasonable to me.

Since this seems to be working as expected now, I'll close the bug as fixed.

Markus Mützel <mmuetzel>
Group administrator
Wed 15 Apr 2020 07:37:34 PM UTC, comment #22: 
  1. should work fine there, but yes, nullptr is better.


I don't know how to test whether the user will want to use ftell/fseek on the stream.  I'm also not sure whether the test is needed if the file is only opened for writing.  It seems better to me to try to get the right result.  If someone is worried about performance, maybe don't open the file in text mode.


John W. Eaton <jwe>
Group administrator
Wed 15 Apr 2020 06:41:06 PM UTC, comment #21: 

That fixes the bug for me.
Only downside might be that the performance might be worse now even for the case when the file actually contains the "correct" line endings. The work around is only really needed if the file has the "wrong" line endings (and the user cares about ftell).
But hopefully MS will fix the bug (and the run time test will de-activate the work around).

Not sure if we care about those kind of things:

diff --git a/liboctave/system/lo-sysdep.cc b/liboctave/system/lo-sysdep.cc
--- a/liboctave/system/lo-sysdep.cc
+++ b/liboctave/system/lo-sysdep.cc
@@ -212,7 +212,7 @@
                          });

       if (set_nonbuffered_mode)
-        ::setvbuf (fptr, 0, _IONBF, 0);
+        ::setvbuf (fptr, nullptr, _IONBF, 0);

       while (true)
         {


Markus Mützel <mmuetzel>
Group administrator
Wed 15 Apr 2020 03:35:21 AM UTC, comment #20: 

I ended up pushing the following changeset on stable:

http://hg.savannah.gnu.org/hgweb/octave/rev/6cccc3c82175

It will be included in the Octave 6 release.

John W. Eaton <jwe>
Group administrator
Mon 13 Apr 2020 07:14:48 PM UTC, comment #19: 

Markus: thanks for finding the visual studio bug info.

Until the problem is fixed, I think a reasonable solution for us is to call "setvbuf (FID, _IONBF, 0, 0)" on Windows systems when opening files in text mode.  Maybe we could also create a simple test to run when Octave first needs to do this that could determine whether the workaround is needed.  Then we would only do this when we detect the problem.  But for now, I propose the following simpler change:


diff --git a/libinterp/corefcn/file-io.cc b/libinterp/corefcn/file-io.cc
--- a/libinterp/corefcn/file-io.cc
+++ b/libinterp/corefcn/file-io.cc
@@ -449,6 +449,15 @@ do_stream_open (const std::string& name,
         {
           FILE *fptr = octave::sys::fopen (fname.c_str (), mode.c_str ());

+#if defined (__WIN32__)
+          // FIXME: Work around fseek/ftell bug on Windows systems.  See
+          // Octave bug #58055.  This should really be enabled only if
+          // fseek/ftell require setting _IONBF to work properly.
+
+          if (mode.find ('t') != std::string::npos)
+            ::setvbuf (fptr, NULL, _IONBF, 0);
+#endif
+
           retval = octave_stdiostream::create (fname, fptr, md, flt_fmt,
                                                encoding);


John W. Eaton <jwe>
Group administrator
Sat 11 Apr 2020 05:14:08 PM UTC, comment #18: 

I see the same results that jwe describes when using _fseeki64 and _ftelli64. However, when using fseeko64 and ftello64 (like in the pasted code), the results are as expected. Also fseeko and ftello works:

initial pos: 0
char: 102, pos: 1
char: 10, pos: 3
char: 111, pos: 4
char: 10, pos: 6
found beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
reading again from beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18

I tried by compiling jwe's code with gcc in the msys2 environment (mingw64) that comes with MXE Octave and replaced the defines with the respective functions for the tests.

Looking at the gnulib sources, I don't know how we could end up calling _fseeki64 and _ftelli64 (on mingw64).
If I correctly understand, we should be ending up calling fseeko and ftello more or less directly.

If I change "foobar.txt" to have LF line endings, I see the following (for ftello, fseeko):

initial pos: 0
char: 102, pos: -5
char: 10, pos: -3
char: 111, pos: -2
char: 10, pos: 0
found beginning of third line (idx = 0)
char: 111, pos: 1
char: 10, pos: 3
char: 98, pos: 4
char: 10, pos: 6
char: 97, pos: 7
char: 10, pos: 9
char: 114, pos: 10
char: 10, pos: 12
reading again from beginning of third line (idx = 0)
char: 102, pos: -5
char: 10, pos: -3
char: 111, pos: -2
char: 10, pos: 0
char: 111, pos: 1
char: 10, pos: 3
char: 98, pos: 4
char: 10, pos: 6
char: 97, pos: 7
char: 10, pos: 9
char: 114, pos: 10
char: 10, pos: 12


This seems to be a known issue:
https://developercommunity.visualstudio.com/content/problem/425878/fseek-ftell-fail-in-text-mode-for-unix-style-text.html

> As a workaround, you can disable stdio buffering by calling setvbuf() with the _IONBF option, though this will decrease performance for programs that do many small reads.


That workaround seems to work for me (see attachment).

So one solution would be to implement the workaround (with the potential performance impact).
Or we could better document that files not using CRLF line endings should be opened in binary mode if the user wants to use ftell on Windows.

(file #48815)

Markus Mützel <mmuetzel>
Group administrator
Sat 11 Apr 2020 01:02:51 PM UTC, comment #17: 

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.


John W. Eaton <jwe>
Group administrator
Fri 10 Apr 2020 11:36:08 PM UTC, comment #16: 

The results from ftello are strange, but passibly consistent with what I reported.  To the actual, true offset, one needs to add or subtract 1 multiplied by the number of lines remaining.  In this case, the true position is 1, and there are 6 lines in "foobar" as a column vector in the file.  Hence the position is 7.

Within Octave, it was subtraction rather than addition.  The true position should have been 52, but the reported position was 29 which was the result if the  one had to subtract the number of lines remaining.

Rik <rik5>
Group administrator
Fri 10 Apr 2020 08:19:14 PM UTC, comment #15: 

I see strange results with some small programs that don't rely on Octave.  I get reasonable results if using ftell/fseek but not if using _ftelli64 and _fseeki64 (required to handle large files).

Here is the test program:


#include <stdio.h>

#if defined (LARGE_FILES)
typedef __int64 offset_type;
#define xftell ftello64
#define xfseek fseeko64
#else
typedef long offset_type;
#define xftell ftell
#define xfseek fseek
#endif

int main (void)
{
  int c;
  int line_count = 1;
  offset_type idx = 0;
  FILE *fid;

  fid = fopen ("foo.txt", "rt");
  printf ("initial pos: %ld\n", (long) xftell (fid));
  while ((c = fgetc (fid)) != EOF)
    {
      offset_type pos = xftell (fid);
      printf ("char: %d, pos: %ld\n", c, (long) pos);

      if (c == '\n' && ++line_count == 3)
        {
          idx = pos;
          printf ("found beginning of third line (idx = %ld)\n",
                  (long) idx);
        }
    }

  printf ("reading again from beginning of third line (idx = %ld)\n",
          (long) idx);

  if (xfseek (fid, idx, SEEK_SET) < 0)
    {
      printf ("SEEK FAILED!\n");
      return 1;
    }

  while ((c = fgetc (fid)) != EOF)
    printf ("char: %d, pos: %ld\n", c, (long) xftell (fid));

  fclose (fid);

  return 0;
}


The input file is just


f
o
o
b
a
r


using CRLF line endings.  The program is supposed to open the file for reading in text mode, read the file one character at a time and display the characters (as integers) and report file position after each character is read.  The position of the beginning of the third line is saved, then after reading the file once, the position is set to the saved position and the rest of the file is read again.  When using ftell/fseek, I get the expected result:


initial pos: 0
char: 102, pos: 1
char: 10, pos: 3
char: 111, pos: 4
char: 10, pos: 6
found beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
reading again from beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18

char: 102, pos: 1
char: 10, pos: 3
char: 111, pos: 4
char: 10, pos: 6
found beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
reading again from beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18


Note that the file position jumps by two when it returns the LF character.  That makes sense as it is skipping the CR character because the file was opened in text mode.

But when using _ftelli64/_fseeki64, I see the following strange result:


initial pos: 0
char: 102, pos: 7
char: 10, pos: 8
char: 111, pos: 9
char: 10, pos: 10
found beginning of third line (idx = 10)
char: 111, pos: 11
char: 10, pos: 12
char: 98, pos: 13
char: 10, pos: 14
char: 97, pos: 15
char: 10, pos: 16
char: 114, pos: 17
char: 10, pos: 18
reading again from beginning of third line (idx = 10)
char: 10, pos: 14
char: 97, pos: 15
char: 10, pos: 16
char: 114, pos: 17
char: 10, pos: 18


WTF is the offset 7 after the first character is read?

Is _ftelli64 completely unreliable for files opened in text mode or am I missing something?  I don't care what the numerical values of the offsets are, but I believe we should be able to use  values from ftell to restore saved file positions even when using files opened in text mode, at least if there has been no change in file contents between the ftell and fseek.

John W. Eaton <jwe>
Group administrator
Thu 09 Apr 2020 11:44:26 PM UTC, comment #14: 

I stepped through the code with gdb and the ftell() goes immediately down through wrappers to library code.  This suggests that it isn't Octave, but gnulib or the libraries on Windows that are getting the file position wrong.

Rik <rik5>
Group administrator
Thu 09 Apr 2020 07:26:43 PM UTC, comment #13: 

OK, looking again, I see that if you are just using fseek with SEEK_SET to return to a position returned by ftell, it should work, even in text mode.

If you do something like


fid = fopen ("some_file", "rt");
k = 0;
while (k++ < 100)
  c = fread (fid, 1);
  if (c < 0) break; endif
  printf ("%d: %d\n", ftell (fid), c);
endwhile


on a Windows system when "some_file" uses LF line-endings, does the file position returned by ftell jump by 2 when the LF character (ASCII 10) is read?

Or is the incorrect count just a problem when using fgetl/fgets to read the file?

John W. Eaton <jwe>
Group administrator
Thu 09 Apr 2020 05:52:21 PM UTC, comment #12: 

ftell is not reliable for files opened in text mode.

If I understand correctly, when you open a file in text mode on a Windows system, then CRLF line endings are translated.  Octave will only see a LF ('\n') character.  I don't think that is something that Octave does, but is a feature of opening and reading a file in text mode.

Maybe we can improve the documentation.

John W. Eaton <jwe>
Group administrator
Thu 09 Apr 2020 03:15:39 PM UTC, 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)

Rik <rik5>
Group administrator
Thu 09 Apr 2020 07:38:00 AM UTC, comment #10: 


>> tst_58055_3


### First 4 lines of file ###
ans = 1234 line1
ans = 12345 line2
ans = 123456line3
ans = 1234567 line4
### Current file position ###
fpos =  47
### Line 5 ###
first__pass = 12345678 line5
### Count lines in file ###
linecount =  5
ans =  6
ans =  7
ans =  8
ans =  9
### Status of fseek call ###
status = 0
### File position after fseek call ###
fpos =  47
### Line 5 second time ###
second_pass = ine4
### Line 6 (should be) ###
ans = 12345678 line5

>>

Toby <streumix>
Thu 09 Apr 2020 07:36:48 AM UTC, comment #9: 


>> tst_58055_2


### First 4 lines of file ###
ans = 1234 line1
ans = 12345 line2
ans = 123456line3
ans = 1234567 line4
### Current file position ###
fpos =  29
### Line 5 ###
first__pass = 12345678 line5
### Count lines in file ###
linecount =  5
ans =  6
ans =  7
ans =  8
ans =  9
ans =  10
ans =  11
ans =  12
ans =  13
ans =  14
ans =  15
ans =  16
ans =  17
ans =  18
ans =  19
ans =  20
ans =  21
ans =  22
ans =  23
ans =  24
ans =  25
ans =  26
ans =  27
### Status of fseek call ###
status = 0
### File position after fseek call ###
fpos =  52
### Line 5 second time ###
second_pass = 12345678 line5
### Line 6 (should be) ###
ans = 1234567 line6

>>


Toby <streumix>
Wed 08 Apr 2020 12:52:40 AM UTC, comment #8: 

I think the problem is with ftell.

Can you download and run the attached tst_58055_2.m which makes use of dummy.txt?  Just upload the results as before.

And for confirmation, can you download and run tst_58055_3.m which also requires downloading dummy3.txt.



(file #48780, file #48781, file #48782)

Rik <rik5>
Group administrator
Tue 31 Mar 2020 06:21:56 AM UTC, comment #7: 

Sorry for not being precise enough in my prior comment. A file encoded with CRLF works as expected (like LF on a Linux system). fpos() + fseek() get the file pointer back exactyl to where you've been before.

Here's the output of the modified script ofr the file encoded with LF line breaks:




>> tst_58055

### First 4 lines of file ###
ans = 1234 line1
ans = 12345 line2
ans = 123456line3
ans = 1234567 line4
### Current file position ###
fpos =  29
### Line 5 ###
first__pass = 12345678 line5
### Count lines in file ###
linecount =  5
ans =  6
ans =  7
ans =  8
ans =  9
ans =  10
ans =  11
ans =  12
ans =  13
ans =  14
ans =  15
ans =  16
ans =  17
ans =  18
ans =  19
ans =  20
ans =  21
ans =  22
ans =  23
ans =  24
ans =  25
ans =  26
ans =  27
### Status of fseek call ###
status = 0
### File position after fseek call ###
fpos =  29
### Line 5 second time ###
second_pass = 56line3
### Line 6 (should be) ###
ans = 1234567 line4
>>

And for reference (confirmation):
fpos =  56 when operating on the file encoded with CRLF.

Toby <streumix>
Mon 30 Mar 2020 03:01:14 PM UTC, comment #6: 

Only somewhat helpful, but I can confirm that on Linux the script behaves as expected.  This is a Windows-specific issue.

I've uploaded a modified test script as tst_58055.m.  Could you run it on a Windows platform and post the results?  In particular, it checks the status output of the fseek call to make sure that nothing obviously went wrong there.

The results for Linux are


### First 4 lines of file ###
ans = 1234 line1
ans = 12345 line2
ans = 123456line3
ans = 1234567 line4
### Current file position ###
fpos =  56
### Line 5 ###
first__pass = 12345678 line5
### Count lines in file ###
linecount =  5
ans =  6
ans =  7
ans =  8
ans =  9
ans =  10
ans =  11
ans =  12
ans =  13
ans =  14
ans =  15
ans =  16
ans =  17
ans =  18
ans =  19
ans =  20
ans =  21
ans =  22
ans =  23
ans =  24
ans =  25
ans =  26
ans =  27
### Status of fseek call ###
status = 0
### File position after fseek call ###
fpos =  56
### Line 5 second time ###
second_pass = 12345678 line5
### Line 6 (should be) ###
ans = 1234567 line6


Also, I couldn't quite tell from your response whether it made a difference if the text file was encoded with newlines which match the platform (LF for Linux, CRLF for Windows).  I've uploaded a version of dummy.txt called dummy.CRLF.txt which has Windows line endings.  Could you modify the script to


fopen ("dummy.CRLF.txt")


and re-run to see if that changes anything.


(file #48711, file #48712)

Rik <rik5>
Group administrator
Sun 29 Mar 2020 08:53:38 PM UTC, comment #5: 

Hi,

there's no issue on Linux either, but I've just figured out that the problem is related to end-of-line handling under Windows.
Once converting the read in text file to CRLF, fpos() is returning the proper location and fseek works as expected.

The strange thing: fgetl() seems to return lines based on LF on Windows, too (like expected on POSIX/UNIX), but internally it obviously does something different breaking fpos() to work. No clue what's going on! Is someone else able to explain?
Is fgetl() supposed to return lines by LF on Windows/DOS?
And if yes, why does fpos() fails to report the proper location?

Toby <streumix>
Sun 29 Mar 2020 06:56:29 PM UTC, comment #4: 

matlab produces this with fseek(istream,fpos,-1), the -1 added since matlab requires an origin argument.


>> version
ans = '9.4.0.813654 (R2018a)'

>> demo
ans = '1234 line1 '
ans = '12345 line2 '
ans = '123456line3 '
ans = '1234567 line4'
first__pass = '12345678 line5 '
second_pass = '12345678 line5 '
ans = '1234567 line6 '


A.R. Burgers <arb>
Sun 29 Mar 2020 02:50:55 PM UTC, comment #3: 

I've attached two files to demonstrate the issue.
When I run these with Octave 5.2.0 on Windows 10 Pro (1809), I get the following output:

>> demo

ans = 1234 line1
ans = 12345 line2
ans = 123456line3
ans = 1234567 line4
first__pass = 12345678 line5
second_pass = 56line3
ans = 1234567 line4

I'd expect first__pass to be identical to second_pass (after reading to the end of the file and jumping back to beginnning of line5 via fseek()).
Toby

Toby <streumix>
Sat 28 Mar 2020 04:18:05 PM UTC, comment #2: 

Marking as "Need Info".  We need a test case that reproduces the issue in order to to stand a chance at debugging it.

Rik <rik5>
Group administrator
Fri 27 Mar 2020 12:53:39 PM UTC, comment #1: 

Can you please provide a script and sample file that demonstrate the problem?

How are you opening reading the file?  Are you using binary or text mode?

John W. Eaton <jwe>
Group administrator
Fri 27 Mar 2020 09:07:22 AM UTC, original submission:  

Hi,

I have older code for text file import, which suddenly fails. It turned out that fgetl() in current version of Octave reads beyond newline character (by a few characters) according to ftell(), though the next call to fgetl() returns the full line. There must be a ninternal buffer involved, which breaks concurrent usage of ftell() / fseek().
Is this an intended change, and concurrent usage of ftell() / fseek() with fgetl() is forbidden in general?

My code does a partial rewind, and that's exactly the reason why it's now failing to work. It used to work in Octave 3 and probably in Octave 4, too. 

Is this a bug, or do I need to rework my code avoiding fgetl()?
(which file I/O functions to cooperate with ftell() and fseek()?)

Regards


Toby <streumix>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48815:  fseek_example_2.c added by mmuetzel (1KiB - application/octet-stream)
file #48794:  tst_58055_4.m added by rik5 (612B - text/x-matlab)
file #48780:  tst_58055_2.m added by rik5 (609B - text/x-matlab)
file #48781:  tst_58055_3.m added by rik5 (612B - text/x-matlab)
file #48782:  dummy3.txt added by rik5 (125B - text/plain)
file #48711:  tst_58055.m added by rik5 (611B - text/x-matlab)
file #48712:  dummy.CRLF.txt added by rik5 (420B - text/plain)
file #48702:  dummy.txt added by streumix (393B - text/plain - Here are two file (demo.m reading from dummy.txt) to demonstrate the issue. )
file #48703:  demo.m added by streumix (274B - application/octet-stream - Here are two file (demo.m reading from dummy.txt) to demonstrate the issue. )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by arb (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by streumix (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-04-16 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-04-15 jwe Item GroupMatlab Compatibility Incorrect Result
        StatusConfirmed Ready For Test
    2020-04-15 mmuetzel Item GroupIncorrect Result Matlab Compatibility
        StatusReady For Test Confirmed
    2020-04-15 jwe Item GroupMatlab Compatibility Incorrect Result
    2020-04-15 jwe StatusConfirmed Ready For Test
    2020-04-11 mmuetzel Attached File- Added fseek_example_2.c, #48815
    2020-04-09 rik5 Attached File- Added tst_58055_4.m, #48794
        StatusNeed Info Confirmed
        Summaryfgetl() reads in beyond newline according to following ftell() ftell() incorrect on MS Windows platforms if file is not encoded with CRLF line endings
    2020-04-08 rik5 Attached File- Added tst_58055_2.m, #48780
        Attached File- Added tst_58055_3.m, #48781
        Attached File- Added dummy3.txt, #48782
        Item GroupNone Matlab Compatibility
    2020-03-30 rik5 Attached File- Added tst_58055.m, #48711
        Attached File- Added dummy.CRLF.txt, #48712
    2020-03-29 streumix Attached File- Added dummy.txt, #48702
        Attached File- Added demo.m, #48703
    2020-03-28 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code