bugGNU Octave - Bugs: bug #35852, fscanf does not read full file

 
 

bug #35852: fscanf does not read full file

Submitter:  None
Submitted:  Thu 15 Mar 2012 04:46:05 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  jordigh
Originator Name:  J Wiebe Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.1
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 26 Jun 2012 08:21:13 PM UTC, comment #32: 

I checked in the following change on stable:

http://hg.savannah.gnu.org/hgweb/octave/rev/980e2d5c83f7

This fix will appear in Octave 3.6.3.  Since it seems to fix the problem, I'm closing this report.

John W. Eaton <jwe>
Group administrator
Fri 22 Jun 2012 02:09:09 PM UTC, comment #31: 

I've built Octave 3.6.2 including the attached patch with MSVC++ 2008 compiler. I can confirm that your patch fixes the bug, at least with the testcases mentioned on this page.
From looking at the code, it seems ok. I can only comment on the code changes though, not on all the dependencies and consequences in Octave.
Thanks, great work!

Roman Hiestand <rhiestan>
Thu 21 Jun 2012 06:37:14 PM UTC, comment #30: 

How about the attached patch?

With the change, we avoid multiple calls to putback between reads and use tellg/seekg ot reset the stream position, but only if there is a failure.  So there should be no problem when reading valid files with Inf, NaN, NA or just plain numbers.  The only problem I see is that the stream positioning might not work correctly when reading streams that don't format match expectations.  Repositioning should work properly when reading from actual files opened in binary mode.  Probably not when reading from pipes, and maybe not if using text mode files (I can't remember what happens there) but Octave opens files in binary mode by default on all systems.

But in any case, if you need robust parsing, you probably shouldn't be relying on handling errors with scanf anyway -- look at where the read pointer ends up for things like '2e+x' with the '%f' format (same behavior in C, so this is not a problem unique to Octave).

But at least this change should fix the original problem, which was apparently random failures when reading valid input files.

If you agree that this change looks OK, I'll apply it to the stable branch and the fix will appear in 3.6.3.

(file #26079)

John W. Eaton <jwe>
Group administrator
Tue 19 Jun 2012 01:02:45 PM UTC, comment #29: 

If we rely on stringstreams for functions like read_inf_nan_na to work, then those functions should be changed to require stringstreams instead of generic istreams.  Or we need to find another way to do this job.

John W. Eaton <jwe>
Group administrator
Tue 19 Jun 2012 09:00:57 AM UTC, comment #28: 

I guess, since stringstreams are backed with a string, they are not buffered and therefore do not show the issue.
I've tested your program with Microsoft Visual C++ 2008 SP1 compiler and MinGW 4.5.3. Just for fun, I tried Cygwin gcc 4.6.2. All of them produced exactly the same file (see attachment), except for the Cygwin which created a file with Unix line-endings and the other two a file with Windows line-endings.

(file #26060)

Roman Hiestand <rhiestan>
Mon 18 Jun 2012 07:56:11 PM UTC, comment #27: 

Do stringstreams also have this limitation with MSFT's implementation? If not, we can use stringstreams to buffer the fstream reading.

Can you please compile and run the attached program with MSFT's implementation of C++ and show me the output? (out.lol)

Thanks!

(file #26055)

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Wed 13 Jun 2012 02:25:13 PM UTC, comment #26: 

With the proposed patch to discard '+' and change the sign if '-' has been read, what happens if the input stream contains something like '-X'?  The read will fail, but I think the read pointer will be positioned at 'X' then instead of at the '-' character.  I think that could cause trouble also.  Shouldn't a failed conversion leave the input pointer unchanged?

Note that saving the stream position and seeking won't work reliably either, because seeking is not guaranteed to work if someone has opened the file in text mode on a Windows system.

John W. Eaton <jwe>
Group administrator
Wed 13 Jun 2012 07:13:14 AM UTC, comment #25: 

Jordi: You are welcome to look over my shoulder as I reproduce the bug with the MinGW build of Octave 3.6.1 :-) And I can assure you that it uses libstdc++6. It only uses msvcrt.dll, which contains functions of the C standard library, not C++. Anyway, MinGW and Visual C++ have a different name mangling for C++ methods, and are therefore incompatible.

John: I haven't implemented a parser for quite some time, but I would break up the input into words, put each word into a std::string and then process it individually. But I can imagine that this would require a lot of changes in the code.

As a compromise I propose to fix the bug at hand in octave_read_value using my patch (and applying it also for the float version which I overlooked), and attack the problem in read_inf_nan_na later.

Roman Hiestand <rhiestan>
Tue 12 Jun 2012 04:41:28 PM UTC, comment #24: 

I think they only problem areas are in the functions in liboctave/lo-utils.cc that read doubles and attempt to handle reading "Inf" and "NaN".

I don't know how to write those functions if it is only possible to look one character ahead in the input stream.  For example, if the input contains "+Impossible", we have to read "+Im" before we can decide that this doesn't match "+Inf".  Then we should fail, but the stream read pointer should be left pointing at the "+".  Do you have some ideas about how to do that with single-character lookahead?  Or maybe I'm misunderstanding the problem.

Yes, we already use a custom stream class.  As I recall, we do that so we can implement Matlab-compatible fseek and ftell functions and perhaps some other stdio-style functions for the Octave interpreter.  If we modify those stream functions to handle buffering for arbitrary lookahead (or even just a fixed limit large enough for Octave's needs) and then expect the functions in lo-utils.cc to depend on that buffering behavior, we would need to change them so that they take the special octave stream type as an argument instead of a generic istream.

John W. Eaton <jwe>
Group administrator
Tue 12 Jun 2012 01:52:35 PM UTC, comment #23: 

Okay, fair enough, I'll take Bjarne's word for it.

Kinda annoying, though. This is a limitation of MSFT's C++ stdlib library, btw. I had people friends this on mingw, and it works as expected there. It's only MSFT's C++ stdlib that fails this way.

I don't believe people running the mingw32 build of Octave who said it was also failing there. ;-) Or perhaps the mingw32 build is somehow using the same MSFT C++ stdlib.

So, it looks like you're right, but we need to patch more than just the one location you patched. I'll work on it later today hopefully with a patch ready by tomorrow, unless you beat me to it.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Tue 12 Jun 2012 09:35:29 AM UTC, comment #22: 

Yes, I found the following quote In "The C++ Programming Language" by Bjarne Stroustrup, (I have the third edition), chapter 21.6.2 "Input Streams and Buffers":

The putback() function allows a program to put an unwanted character back to be read some other time, as shown in §21.3.5. The unget function puts the most recently read character back. Unfortunately, backing up an input stream is not always possible. For example, trying to back up past the first character read will setios_base::failbit. What is guaranteed is that you can back up one character after a successful read.

I was also trying to find the respective hint in the documentation for libstdc++, but it's not very clear there. In the entry for std::basic_istream::putback I found:

If rdbuf() is not null, calls rdbuf()->sputbackc(c).
If rdbuf() is null or if sputbackc() fails, sets badbit in the error state.

In the documentation for std::basic_streambuf::sputbackc() I found

Similar to sungetc(), but __c is pushed onto the stream instead of the previous character. If successful, the next character fetched from the input stream will be __c.

It states that it can fail, but doesn't specify in what cases.

I found other interesting documents on the web:
http://stackoverflow.com/questions/6152956/are-there-any-guarantees-with-unget
http://bytes.com/topic/c/answers/62925-unget-vs-putback

My personal summary: Calling putback() once after get() is guaranteed to work, but not more. If you really want to be platform-independent (and I think you should), you should eliminate successive calls to putback().
Alternatively, since Octave seems to have its own streambuf class (c_file_ptr_buf), you could extend it to allow for more putback()s.

Roman Hiestand <rhiestan>
Mon 11 Jun 2012 09:46:36 PM UTC, comment #21: 

There are a bunch of other locations in lo-utils.cc that we call istream::putback more than once, more than the ones you've patched about. It seems awkward to "fix" all of those, when I can't even find a clear indication that istream::putback shouldn't be called this way. Can you find a C++ reference, not C, that says we're doing something wrong, or how should we do this correctly?

I am still probably going to apply your patch, but I want to know what the right thing to do here is. As far as I can tell, we're calling istream::putback correctly.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 07 Jun 2012 04:01:11 PM UTC, comment #20: 

You're welcome.
I'm not sure whether we can blame MS' C++ library here. Please keep in mind that the MinGW build of Octave 3.6.1 has the same bug, and this one uses libstdc++. I don't know what the common denominator is.
I think it's possible that the same bug exists on *nix too, but it simply does not occur because the buffer size is very big (on Windows, ungetc's buffer size is 4096 bytes). The error happens if the '-' is the last character in the old buffer, and the first digit triggers a reload. There's a certain probability for that pattern, with big buffers this probability decreases.

About quoting: Sure, go ahead.
Thanks for reviewing and including my patch!

Roman Hiestand <rhiestan>
Thu 07 Jun 2012 03:33:48 PM UTC, comment #19: 

Fantastic, thanks Roman, for the careful debugging and patch.

I'm not completely convinced we're doing something wrong yet, since we're not calling C's ungetc, but rather C++'s istream::putback. This might be a bug in MSFT's C++ stdlib implementation. I can't find any description in the C++ standard that we're doing something wrong.

I'm going to investigate the problem a bit more to see what the right thing to do here is, but I will most likely apply your patch within a short while. Is it ok to credit you as "Roman Hiestand <rhiestan@swissonline.ch>"?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Tue 05 Jun 2012 11:06:35 AM UTC, comment #18: 

I think I have found the problem. With the generous help of Michael Goffioul I was able to build a debug version of Octave 3.6.2 on Windows (MSVC).
The problem is that ungetc/putback on a stream can fail in certain conditions, which is the case here. The condition in which ungetc/putback can fail is
when previously there were two successive calls to std::istream::get(), when for the second one the buffer was empty and got refilled. The first putback/ungetc
then works, while the second fails. It is questionable anyway to call putback/ungetc twice in a row, I found several comments on the web that this might fail also with glibc.

In the header of ungetc this is documented (Copyright Microsoft):
*Exit:

  •       returns ch
  •       returns EOF if tried to push EOF, stream not opened for reading or
  •       or if we have already ungetc'd back to beginning of buffer.


See also
http://msdn.microsoft.com/en-us/library/29hykw2y%28VS.90%29.aspx
http://www.gnu.org/software/libc/manual/html_node/How-Unread.html#How-Unread

In our case, ungetc then returns EOF, the eof-bit is set in the stream and fscanf is aborted. This is the call stack where the error occurs:

> msvcr90.dll!_ungetc_nolock(int ch=45, _iobuf * str=0x729f7408)  Line 73 C

  msvcr90.dll!ungetc(int ch=45, _iobuf * stream=0x729f7408)  Line 53 + 0xb bytes C
  vc90-liboctinterp-1.dll!c_file_ptr_buf::pbackfail(int c=45)  Line 96 + 0x25 bytes C++
  msvcp90.dll!std::basic_streambuf<char,std::char_traits<char> >::sputbackc(char _Ch='-')  Line 143 C++
  msvcp90.dll!std::basic_istream<char,std::char_traits<char> >::putback(char _Ch='-')  Line 771 + 0x15 bytes C++
  vc90-liboctave-1.dll!0073f6e5()
  [Frames below may be incorrect and/or missing, no symbols loaded for vc90-liboctave-1.dll]
  vc90-liboctinterp-1.dll!octave_scan<double>(std::basic_istream<char,std::char_traits<char> > & is={...}, const scanf_format_elt & fmt={...}, double * valptr=0x0018ecb4)  Line 1233 + 0xa bytes C++
  vc90-liboctinterp-1.dll!do_scanf_conv<double >(std::basic_istream<char,std::char_traits<char> > & is={...}, const scanf_format_elt & fmt={...}, double valptr=0x0018ecb4, Matrix & mval={...}, double * data=0x08721d48, int & idx=18767, int & conversion_count=18767, int nr=7, int max_size=28672, bool discard=false)  Line 1253 + 0x11 bytes C++
  vc90-liboctinterp-1.dll!octave_base_stream::do_scanf(scanf_format_list & fmt_list={...}, int nr=7, int nc=-1, bool one_elt_size_spec=false, int & conversion_count=18767, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & who="fscanf")  Line 1769 + 0x31 bytes C++
  vc90-liboctinterp-1.dll!octave_base_stream::scanf(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fmt="%f", const Array<double> & size={...}, int & conversion_count=18767, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & who="fscanf")  Line 1943 + 0x2b bytes C++
  vc90-liboctinterp-1.dll!octave_stream::scanf(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fmt="%f", const Array<double> & size={...}, int & count=18767, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & who="fscanf")  Line 3689 + 0x1e bytes C++
  vc90-liboctinterp-1.dll!octave_stream::scanf(const octave_value & fmt={...}, const Array<double> & size={...}, int & count=18767, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & who="fscanf")  Line 3707 + 0x22 bytes C++
  vc90-liboctinterp-1.dll!Ffscanf(const octave_value_list & args={...}, int __formal=1)  Line 1161 + 0x24 bytes C++

For some reason the debugger had problems with liboctave, but there it is in the function template <> double octave_read_value (std::istream& is), line 284 in lo-utils.cc.

As a fix I propose the following: Remove the second putback, negate the double. In the '+' case, leave out putback altogether.
Please tell me what you think, I'm open for feedback/suggestions/criticism. Should you accept the patch, I'd be glad if one of the Octave developers could merge it into the source repository.
I have run all the test cases on this page (except the %i case), all work fine.


(file #25985)

Roman Hiestand <rhiestan>
Wed 23 May 2012 06:15:25 PM UTC, comment #17: 

OK, it turns out that the bug reported to the mailing list (bug.m and bug.dat) is not really a bug in Octave.  The script uses "%i:%i:%i" to parse times of the form "06:08:30" and that fails because %i interprets hex, octal, and decimal integers depending on the contents of the file that is being read.  Hex numbers begin with 0x or 0X and octal numbers begin with 0.  So 08 is not parsed as "8" but instead as 0 because it initially looks like an octal number but 8 is not an octal digit.  This is not a bug.  If you want to always parse decimal numbers, use '%d' instead of '%i'.

On a related note, while investigating this problem report, I did find a bug with not properly ignoring leading whitespace when handling '%i' formats.  That problem is fixed in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/757f729fd41d

John W. Eaton <jwe>
Group administrator
Wed 23 May 2012 07:04:57 AM UTC, comment #16: 

Thank you John for attending to this problem.

Please be aware that there are two separate bugs:

 - The bug reported by N. Christopher Perry to the mailing list, reproducible with bug.m and bug.txt. I was able to reproduce the bug on all available platforms and Octave versions I have access to (3.6.1 on Ubuntu, 3.2.4 until 3.6.1 on Windows).

 - The bug reported by Josh, Pascal, Todd and me that only affect Windows builds 3.6.0 and 3.6.1.

To answer Jordis question: Yes, I was able to reproduce the bug with my test program (fscanf_errortestcase.m) with 3.6.1 mingw32 and MSVC builds (VS2008 and VS2010), all downloaded from OctaveForge. The Cygwin version of Octave 3.6.1 does not produce the error.

Roman Hiestand <rhiestan>
Tue 22 May 2012 08:59:47 PM UTC, comment #15: 

I can duplicate this problem on my system with the bug.m and bug.dat files I attached earlier.  I'm looking at the problem now.

John W. Eaton <jwe>
Group administrator
Tue 22 May 2012 04:10:59 PM UTC, comment #14: 

I guess it's  bug that it's affecting a lot of people, but until we get someone who can actually do Windows development, it is unlikely we'll get this fixed.

Can the Windows users confirm that this happens both with the mingw32 and MSVC builds?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Tue 22 May 2012 03:34:59 PM UTC, comment #13: 

I have the same problem with all newer Octave versions (tested on Vista 32 bit and Win7 64 bit).
Please find a small test program attached to this comment (fscanf_testcase.m). It creates its own test file, then tries to read it.
The Octave versions 3.2.4 and 3.4.3 work correctly, while the versions 3.6.1 and 3.6.0 (gcc 4.6.2) show the error. All builds have been downloaded from the OctaveForge homepage (http://sourceforge.net/projects/octave/files/Octave%20Windows%20binaries/).
Also, the Linux version of Octave 3.6.1 works fine (original package from Ubuntu 11.10 x64).

Expected output:
octave.exe:15> fscanf_errortestcase
ans =

       5   40000

ans =

       7   40000

Wrong output, Octave 3.6.1:
octave:26> fscanf_errortestcase
ans =

      5   4000

ans =

      7   2681


(file #25905)

Roman Hiestand <rhiestan>
Mon 16 Apr 2012 01:31:07 PM UTC, comment #12: 

Same issue with Octave 3.6.1 on Windows XP SP3.
It seems the issue occurs only under Windows and comes from a matter of file "formatting":
If the file to be read is
     with Line Feed (LF) formatting only: ok
     with Carriage Return and Line Feed (CRLF) formatting: NOT ok


1°/ The function
function [z]=read_data(name)
f=fopen(name);
line1=fgets(f);
line2=fscanf(f,'%f',4);
line3=fscanf(f,'%d',2);
nx=line3(1);
ny=line3(2);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
z=fscanf(f,'%f',nx*ny);
fclose(f);

% FOR DEBUG
size_z = size(z)


2°/ Data to be read
Data_CRLF.txt is the file that should be read. It has a CRLF formatting.
Data_LF.txt contains the same data but the formatting is only a LF one.
(starting from line number 4, Data_*.txt contains 40401 numbers (40401 = 201*201))





Under Octave 3.6.1 on Windows XP (and QtOctave 0.10.1)
read_data('Data_LF.txt')
size_z =
     40401   1
it is the correct expected answer!!

read_data('Data_CRLF.txt')
size_z =
     1099   1
it is NOT the correct expected answer !!


Other results:
Under MATLAB (6.1.0.450 (R12.1)): read_data('Data_LF.txt') gives the correct answer
Under MATLAB(6.1.0.450 (R12.1)): read_data('Data_CRLF.txt') gives the correct answer

Under Windows XP Octave 3.6.0: read_data('Data_CRLF.txt') gives UNCORRECT answer
Under Windows XP Octave 3.6.0: read_data('Data_LF.txt') gives correct answer

Under Unix/linux: Octave version 3.6.0-rc1: read_data('Data_CRLF.txt') gives the correct answer

Under Unix/linux: Octave version 3.7.0+: read_data('Data_CRLF.txt') gives the correct answer

With cygwin, with Octave 3.6.1: read_data('Data_CRLF.txt') gives the correct answer




(file #25658, file #25659, file #25660, file #25661)

Pascal31 <pascal31>
Thu 12 Apr 2012 01:42:17 AM UTC, comment #11: 

I am having the same issue with 3.6.1 on Windows 7 (64bit).

The same files are read fine with 3.2.4 and 3.4.3. There appears to be a problem with 3.6.0 and 3.6.1 on Windows with fscanf that is causing it to prematurely stop reading files.

Todd Harrington <stellartodd>
Tue 27 Mar 2012 03:30:12 PM UTC, comment #10: 

My example came from a set of old bug reports that were never correctly posted to the -email is unavailable- mailing list.  I'm adding the originator of that report to the mail notification list for this bug report.

Sorry about not posting the old report until now.

John W. Eaton <jwe>
Group administrator
Tue 27 Mar 2012 03:23:05 PM UTC, comment #9: 

I have an example (attached as bug.m and bug.dat) that shows similar behavior with fscanf not reading an entire file when I think it should.  The file bug.dat has 3743 lines but fscanf only reads the first 92 lines completely and then the first 4 fields of line 93.  I don't see anything strange in the file at line 93.  Line 3736 has some non-numeric data that would cause the format to fail, but even when removing that line, fscanf stops early.


(file #25478, file #25479)

John W. Eaton <jwe>
Group administrator
Thu 22 Mar 2012 03:20:56 PM UTC, comment #8: 

Since I'm unable to reproduce it, I imagine it must be one of those "BLAS is wrong" kind of problems that happens to be manifesting in an unexpected way on your computer. Can you try with a different BLAS?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 22 Mar 2012 03:04:12 PM UTC, comment #7: 

Any idea what the problem may be?  We have MATLAB at work and MATLAB and Octave 3.2.4 read the file correctly.  It appears to be a problem with Octave 3.6.0

Thanks,
Josh

jwiebe <jwiebe>
Fri 16 Mar 2012 06:09:53 PM UTC, comment #6: 

The original file was too large to upload so I truncated it. Either way I run into the same problem in v3.6.0. The file has 9876 lines, but v3.6.0 will only read 649 lines if I suppress output with a semicolon or 2716 lines if I don't use the semicolon.  Using load, I get 5139 lines.  Using v3.2.4 fscanf reads all 9876 lines.

octave:3> fid=fopen('sample_short.txt', 'rt');
octave:4> data=fscanf(fid,'%f', [3, inf])';
octave:5> size(data)
ans =

   649     3

octave:6> a=load('sample_short.txt');
octave:7> size(a)
ans =

   5139      3


octave-3.2.4.exe:2> fid=fopen('sample_short.txt', 'rt');
octave-3.2.4.exe:3> data=fscanf(fid,'%f', [3, inf])';
octave-3.2.4.exe:4> size(data)
ans =

   9876      3

jwiebe <jwiebe>
Thu 15 Mar 2012 08:31:07 PM UTC, comment #5: 

This can't be the same file... In your other attachment, you seem to working with a file with at least 57144 lines and the one you posted only has 9876 lines. It may have gotten truncated. Can you try uploading again, but zipping it? Attachments have a maximum size limit.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 15 Mar 2012 08:22:12 PM UTC, comment #4: 

Yes, this is the exact file I'm having trouble with.  Produced with Win7 on the same computer.  What puzzles me is that Octave 3.2.4 loads the file correctly but 3.6.0 doesn't.

jwiebe <jwiebe>
Thu 15 Mar 2012 08:08:21 PM UTC, comment #3: 

I still can't reproduce it... Both load and fscanf produce identical results for me. Is this the precise file on which you're experiencing a crap-out? My only guess is that it's mixing line endings, both CR and CRLF. Did two different OSes edit this precise file?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 15 Mar 2012 07:57:38 PM UTC, comment #2: 

I can't reproduce this problem. Is it possible to get the precise file you're trying to load?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 15 Mar 2012 04:51:36 PM UTC, comment #1: 

Can you please describe the shape, colour, and consistency of the crap fscanf emits? And if possible, also please attach the file on which it craps out.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 15 Mar 2012 04:46:05 PM UTC, original submission:  

The following code works in version 3.2.4 but fails in version 3.6.0

data = fscanf(fid,'%f',[ncol nodeCount])';

after some header lines the file looks like this:

648075.500000 7781634.500000 -17.139
648076.500000 7781586.500000 -17.43
648076.500000 7781595.500000 -17.552
648076.500000 7781611.500000 -17.575
648077.500000 7781562.500000 -17.785
648077.500000 7781602.500000 -17.421
...

In v3.2.4 it correctly reads the number of rows corresponding to nodeCount, but in v3.6.0 it craps out at 2716 lines.


Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #26079:  diffs.txt added by jwe (6KiB - text/plain)
file #26060:  out.zip added by rhiestan (24KiB - application/zip)
file #26055:  lol.c++ added by jordigh (436KiB - text/x-c++src)
file #25985:  lo-utils.cc.patch added by rhiestan (509B - application/octet-stream)
file #25905:  fscanf_errortestcase.m added by rhiestan (291B - application/octet-stream - fscanf_testcase.m)
file #25661:  fscanf_formatting_issue.zip added by pascal31 (551KiB - application/x-zip-compressed - All necessary data)
file #25660:  Data_LF.txt added by pascal31 (720KiB - text/plain - All necessary data)
file #25659:  Data_CRLF.txt added by pascal31 (730KiB - text/plain - All necessary data)
file #25658:  read_data.m added by pascal31 (246B - application/octet-stream - All necessary data)
file #25479:  bug.dat added by jwe (241KiB - application/x-ns-proxy-autoconfig)
file #25478:  bug.m added by jwe (380B - text/x-objcsrc)
file #25371:  sample_short.txt added by None (365KiB - text/plain)
file #25370:  sample_terminal.txt added by None (248B - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rhiestan (Updated the item)
  • -email is unavailable- added by pascal31 (Updated the item)
  • -email is unavailable- added by stellartodd (Posted a comment)
  • -email is unavailable- added by jwe
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by jwiebe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by None (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 23 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-06-26 jwe StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2012-06-21 jwe Attached File- Added diffs.txt, #26079
    2012-06-19 rhiestan Attached File- Added out.zip, #26060
    2012-06-18 jordigh Attached File- Added lol.c++, #26055
    2012-06-07 jordigh StatusConfirmed Patch Submitted
        Assigned tojwe jordigh
        Release3.6.0 3.6.1
    2012-06-05 rhiestan Attached File- Added lo-utils.cc.patch, #25985
    2012-05-22 jwe Assigned toNone jwe
    2012-05-22 jordigh StatusWorks For Me Confirmed
    2012-05-22 rhiestan Attached File- Added fscanf_errortestcase.m, #25905
    2012-04-16 pascal31 Attached File- Added read_data.m, #25658
        Attached File- Added Data_CRLF.txt, #25659
        Attached File- Added Data_LF.txt, #25660
        Attached File- Added fscanf_formatting_issue.zip, #25661
    2012-03-27 jwe Carbon-Copy- Added -email is unavailable-
    2012-03-27 jwe Attached File- Added bug.m, #25478
        Attached File- Added bug.dat, #25479
    2012-03-15 None Attached File- Added sample_short.txt, #25371
    2012-03-15 jordigh StatusNeed Info Works For Me
    2012-03-15 None Attached File- Added sample_terminal.txt, #25370
    2012-03-15 jordigh StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code