As described in the upstream report [1], HDF I/O using load/save is broken in 4.0.0. This is a regression with the potential for data loss (almost happened to us!).
The bug is fixed upstream with [2], and I plan on making an SRU request with an updated octave package that includes this patch (will be my first SRU).
To reproduce:
* Extract the attached .tar.gz, which contains test_hdf5_save.m and test_hdf5_load.m from the upstream report.
* Run:
[Octave 3.8]
octave:1> test_hdf5_save
x = 123456789
[Octave 4.0.0]
octave:1> test_hdf5_load
x = 255
And the other way around:
[Octave 4.0.0]
octave:2> test_hdf5_save
x = 123456789
[Octave 3.8]
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
As described in the upstream report [1], HDF I/O using load/save is broken in 4.0.0. This is a regression with the potential for data loss (almost happened to us!).
The bug is fixed upstream with [2], and I plan on making an SRU request with an updated octave package that includes this patch (will be my first SRU).
To reproduce:
* Extract the attached .tar.gz, which contains test_hdf5_save.m and test_hdf5_load.m from the upstream report.
* Run:
[Octave 3.8]
octave:1> test_hdf5_save
x = 123456789
[Octave 4.0.0]
octave:1> test_hdf5_load
x = 255
And the other way around:
[Octave 4.0.0]
octave:2> test_hdf5_save
x = 123456789
[Octave 3.8]
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
[1] http:// savannah. gnu.org/ bugs/?45225 hg.savannah. gnu.org/ hgweb/octave/ rev/d54aa96abad f
[2] http://