[Octave-bug-tracker] [bug #59238] load variables from file: the next saving operation produces a faulty file

[Markus Mützel]

Follow-up Comment #20, bug #59238 (project octave):

OK. I don't know what was going on yesterday. But it looks like I had my eyes
closed when looking at the code...
The binary mode is conditional in `load_save_system::save` in "load-save.cc":

        if (format.type () == BINARY
#if defined (HAVE_HDF5)
            || format.type () == HDF5
#endif
            || format.type () == MAT_BINARY
            || format.type () == MAT5_BINARY
            || format.type () == MAT7_BINARY)
          mode |= std::ios::binary;


So "-text" uses text mode for saving. No wonder there are CRLF line endings.

The files are opened in binary mode *unconditionally* in
`load_save_system::load`. No wonder there are additional CRs in the recovered
string.

Possible options are:
1. Open the file in the same mode for writing and reading. Two possibilities:
  a) Keep the conditional binary mode in `load_save_system::save` and use the
same mode (with the same condition) in `load_save_system::load`. That would
lead to consistent results if the files are saved and loaded on the same OS.
The issue would persist if files saved on Windows would be loaded on Linux (as
an example for two OSs that use different default line endings).
  b) Always use binary mode unconditionally. That would lead to consistent
results also when exchanging files between OSs with different default line
endings. Loading strings with line breaks from broken files (i.e. ones with
CRLF line ending) would continue to be broken.
2. Add additional logic that counts CR characters removes them from the string
and continues to read the missing characters from the save file.

I'd prefer to follow on with option 1.b).
With option 2.a) we'd continue to have issues when exchanging files between
OSs with different default line ending.
Option 2 seems messy and would complicate the code unnecessarily. 
It is easy to "repair" the invalid files that Octave produces until now by
replacing CRLF line endings with LF line endings with third party tools.

What do you think?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59238>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/