Re: failed checks for mingw32 build in octave 3.0.0/3.0.1

[Benjamin Lindner]

Benjamin Lindner wrote:
> Hello,
>
> as correctly pointed out by Tatsuro on the forge mailing list, I move 
> discussion of the mingw32 build here.
>
> I have the following 3 failing tests for 3.0.0 and 3.0.1:
>
> in ov-fcn-handle.cc
>   ***** test
>  a = 2;
>  f = @(x) a + x;
>  g = @(x) 2 * x;
>  h = @log2;
>  f2 = f;
>  g2 = g;
>  h2 = h;
>  nm = tmpnam();
>  unwind_protect
>    save ("-text", nm, "f2", "g2", "h2");
>    clear f2 g2 h2
>    load (nm);
>    assert (f(2),f2(2));
>    assert (g(2),g2(2));
>    assert (g(3),g2(3));
>    unlink (nm);
>    save ("-text", nm, "f2", "g2", "h2");
>  unwind_protect_cleanup
>    unlink (nm);
>  end_unwind_protect
> !!!!! test failed
> error: function handle points to non-existent function

This one is a nasty one.
It is related to the weird behaviour that in mingw32 using tellg() on 
text-mode opened files is not behaving correctly.
See http://www.mingw.org/MinGWiki/index.php/Known%20Problems

The bug manifests itself within octave_fcn_handle::load_ascii 
(std::istream& is) in ov-fcn-handle.cc

The sequence of tellg() calls before the calls to extract_keyword() 
actually *move* the file reading position, thus
  pos = is.tellg();
  is.seekg(pos);
will *not* keep the position the same. Weird, I know.
Thus the statement
  is >> nm;
only partially reads the "@<anonymous>" line, and the following code 
assumes a named function handle, which eventually fails.

I don't know how to fix this.
I tried to change file open mode to binary, which then correctly reads 
anonymous function handles from oct-ascii files, but fails to read any 
other data type due to stray '\r' characters read from a data file with 
'\r\n' line endings (if the data file is in binary text format, 
everything works well, but we need to be able to read '\r\n'-mode data 
files as well) - so this idea is, though simple, not useful.

The second possibility I thought of is getting rid of the 
tellg()/seekg(), but I don't see how this can be done in a clean way 
without inflicting other problems.
Speaking of it - I tried to reason the code in 
octave_fcn_handle::load_ascii and I don't understand why there is the 
tellg()/seekg() sequence here. It look like octave tried to extract a 
keyword, but if it fails to do so, it does not seem to matter?
I did not find a similar coding in the other data types' read_ascii() 
methods.
Is there a way to remove the tellg()/seekg() code for function handles 
in a clean way?

If nothing helps, then there is the possibility to simply not support 
anonymous function handles in octave's ascii data file format in mingw32 
builds. Not nice, though.

any thoughts?

Lindner Benjamin