3.0.4 RC3 (mingw 3.4.5)-2

[Benjamin Lindner]

John W. Eaton wrote:
> On  3-Mar-2009, Benjamin Lindner wrote:
> 
> | John W. Eaton wrote:
> | > On 30-Jan-2009, Benjamin Lindner wrote:
> | > 
> | > | To work around it in octave we need to rethink octave's way to save 
> | > | anonymous function handles in ascii format.
> | > | I have tried something for in the development branch, which allows this 
> | > | test to pass, but it means a small but significant change in the format 
> | > | of saving anonymous function handles. This breaks backwards 
> | > | compatibility, so I'm not really happy about my approach.
> | > 
> | > We can open text files for reading in binary mode.  It just means that
> | > we have to handle the CRLF, CR, and LF line endings ourselves.  We
> | > already do that (more or less) for .m files.  But it would maybe be a
> | > good idea to come up with a unified way of doing it for all of Octave.
> | > 
> | 
> | I have put some thought into this problem and have changed the behaviour 
> | of reading ascii mode data by doing the following
> |   *) files get always opened in binary mode when loading data (saving to 
> | ascii is still done in text mode)
> |   *) walked through the load_ascii( ) method of the various octave_value 
> | derived classes and moved all newline/cr/lf related code into common 
> | functions
> |   *) created ls-ascii-helper.h and ls-ascii-helper.cc and stored the 
> | common functions there
> | 
> | With this, I get rid of the failing test in ov-fcn-handle.cc on mingw. I 
> | have no additional failed tests. Saving and loading in "-text" format 
> | seems to work, I have not encountered problems yet.
> | 
> | I don't have access to matlab, so I could not check what happens with 
> | data files in matlab's text format. I'd appreciate cross-checks.
> 
> I applied this patch with some style changes.  I also had to remove
> this part of the patch:
> 
> | diff -r 97991a9e7a18 -r 1315d5c25fa9 src/ls-oct-ascii.cc
> | --- a/src/ls-oct-ascii.cc	Tue Mar 03 19:28:03 2009 +0100
> | +++ b/src/ls-oct-ascii.cc	Tue Mar 03 10:09:56 2009 +0100
> | @@ -118,14 +119,15 @@
> |  		}
> |  
> |  	      retval = value.str ();
> | +	      skip_until_newline (is, false);
> |  	      break;
> |  	    }
> |  	  else if (next_only)
> 
> Otherwise I saw 6 new failures when running make check.  Why was this
> line added?  Is it needed for systems that have CRLF?  If so, why?

Without this line, I still get a failure in ov-fcn-handle.cc
And I guess the errors Tatsuro reported also base on this.

This line is required because the code

	      if (c != '\n' && c != '\r')
		{
		  value << c;
		  while (is.get (c) && c != '\n' && c != '\r')
		    value << c;
		}

	      retval = value.str ();
	      break;

leaves a stray '\n' in the input stream if line endings are CRLF, since 
the while () loop breaks at the first '\r' and the following '\n' is not 
   removed.

OK, I'll think of a workaround

benjamin