3.0.4 RC3 (mingw 3.4.5)-2

[Benjamin Lindner]

>> 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
> 

Let's see, lap #1.
Could you check with the attached changeset?
This should now be a more consistent behaviour for LF and CRLF files (I 
hope at least)

benjamin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-crlf-ls-oct-ascii.patch
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090318/5bc984aa/attachment.ksh