Possible bug in "load" function in octave 3.0.4

[Benjamin Lindner]

Jaroslav Hajek wrote:
> On Sun, Apr 5, 2009 at 5:56 PM, Benjamin Lindner <lindnerben at gmx.net> wrote:
>> Jaroslav Hajek wrote:
>>> On Sun, Apr 5, 2009 at 12:01 PM, Massimiliano Culpo
>>> <misticoannoiato at yahoo.it> wrote:
>>>> Please find attached a possible bug occurring in octave 3.0.4.
>>>>
>>>> Regards,
>>>> Massimiliano Culpo
>>>>
>>>> _______________________________________________
>>>> Bug-octave mailing list
>>>> Bug-octave at octave.org
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>>>
>>>>
>>> Confirmed; this is quite blatant. Too bad there was no test for ASCII
>>> loading :(
>>> It appears that the changeset fixing CRLF issues on MinGW/Cygwin
>>> http://hg.tw-math.de/release-3-0-x/rev/34b75a47e712
>>> broke things up. Is anyone interested in fixing this in 3.0.x series?
>>> (the simplest fix is of course to just revert the broken patch)
>>> Does not exist in 3.1.5x.
>> Oh shit (sorry for that).
>> Well, since I introduced it, I'll try to see to a fix. I think it should be
>> fixed in 3.0.x
>>
>> Strange that it does not exist in 3.1.x. Has the save/load code been changed
>> from 3.0 -> 3.1 ?
>>
>> benjamin
>>
>>
> 
> Hmmm. Correct me if I'm wrong, but I think your patch was originally
> for 3.1.x. It was (IIRC) Tatsuro who backported ported it for 3.0.x.
> So maybe Tatsuro can comment whether he had made any non-trivial
> modifications. If not, then probably this is an unexpected interaction
> between some changed parts.
> Anyway, I think there were numerous changes to the load/save code
> since 3.0 (as well as most other parts of Octave).
> I also think that this shows that 15 months since the 3.0 fork is
> really too much.
> 

Yep, but I did some backporting on this patch. Then the patch for 3.1.x 
was also updated because it was buggy. Anyway, since this bug is not 
found in 3.1.x I did a comparison of the ascii loading code and found 
the problem.
get_mat_data_input_line() in ls-mat-ascii.cc was eating a whole line 
when it should have only read a newline.
This is done correctly in 3.1.x, the attached changeset aligns the 3.0.x 
code properly.

I get now

B=load("t:\\msh_p2.txt");
size(B)
ans =

    192     2

benjamin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-ascii-load.patch
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090405/935a2876/attachment.ksh