From bug-request at octave dot org Fri Dec 17 09:21:53 2004 Subject: RE: Possible Error in -ascii save/restore From: "John W. Eaton" To: Cc: Date: Fri, 17 Dec 2004 10:22:52 -0500 On 17-Dec-2004, Hallvard dot Paulsen at wartsila dot com wrote: | Hello John, | | I am no C++ programmer, but I did the following (after copying your | source code to a file test.cc) | HPA007 at now2032 ~ | $ g++ test.cc -o TEST | | HPA007 at now2032 ~ | $ ./TEST.exe | line 1 | line 2 | pos = 18 | line 3 | ne 3 | | HPA007 at now2032 ~ | I.e. the same as you get. OK, I think this looks like a bug in the iostream library on Cygwin systems when the filesystem is mounted in text mode. Can someone please report it? If the response is "it is not a bug" then please try to get someone to explain why it is not a bug and what is the proper way to deal with this problem. In the meantime, you can work around the problem by mounting the filesystem in binary (Unix) mode. Then at least Octave will be able to load files that it has saved on the binary mounted filesystem (they will have LF line endings). Octave will still fail to read files that have been saved with DOS (CRLF) line endings, but if you have any files that have been saved that way, I think you can fix them with something like dos2unix or GNU recode. This brings up another issue. Should Octave even try to read files with with CRLF (DOS), CR (Mac), LF (Unix) line endings on all systems? You might have those because you transferred them without doing any translation, or because you are using a shared filesystem that does not provide translation. If we should attempt to allow reading files with any line ending convention on any system, then we need some unified way to do this so that the conversion can happen in one place rather than scattering the code for detecting and dealing with the various line endings all over the code. As it is now, we have some parts of Octave that do this (the parser, when reading M-files) and some that don't (the load-save stuff). If we did have a unified way of translating line endings when reading files, then we could simplify the parser a bit so it would only have to check for '\n', not '\r\n' and '\r' as well. Oh wait, shouldn't all this really be outside the scope of the application? I mean why should every program have to deal with these conversions? Similarly, for writing files, what do you choose? The "native" format? On a Cygwin system, what is that? It depends on the way the filesystem is mounted? Then the filesystem should take care of the translation and applications like Octave should not have to worry about it. Ugh. It is almost 2005 now, and we are still dealing with this kind of nonsense? jwe ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------