|
From: | Markus Mützel |
Subject: | [Octave-bug-tracker] [bug #59238] load variables from file: the next saving operation produces a faulty file |
Date: | Wed, 21 Oct 2020 14:24:21 -0400 (EDT) |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.80 Safari/537.36 Edg/86.0.622.48 |
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/
[Prev in Thread] | Current Thread | [Next in Thread] |