From bug-request at octave dot org Mon Dec 20 09:18:59 2004 Subject: RE: Possible Error in -ascii save/restore From: "John W. Eaton" To: Cc: Date: Mon, 20 Dec 2004 10:20:41 -0500 On 20-Dec-2004, Hallvard dot Paulsen at wartsila dot com wrote: | I've been looking around the http://Cygwin.com site to try to find some | way to report this, but there doesn't seam to be an easy way unless you | are a developer yourself. | | However I found this in the FAQ: http://cygwin.com/faq.html | | [...] | | When processing in text mode, certain values of data are treated | specially. A \n (new line) written to the file will prepend a \r | (carriage return) so that if you `printf("Hello\n") you in fact get | "Hello\r\n". Upon reading this combination, the \r is removed and the | number of bytes returned by the read is 1 less than was actually read. | This tends to confuse programs dependent on ftell() and fseek(). So they are saying that there is no way to use ftell/fseek on a text file with CRLF line endings opened in text mode? Then we would have to open them in binary mode and do the CRLF processing ourselves? This does not seem good. Or have I forgotten something basic, and ftell/fseek should never be assumed to work on text files? | A | Ctrl-Z encountered while reading a file sets the End Of File flags even | though it truly isn't the end of file. This is also potentially bad, but probably doesn't affect Octave because I don't think we would have any ^Z characters in text files. | [...] | | Some people push the notion of globally setting the default processing | mode to binary via mount point options or by setting the CYGWIN | environment variable. But that creates a different problem. In binary | mode, the program receives all of the data in the file, including a \r. | Since the programs will no longer deal with these properly for you, you | would have to remove the \r from the relevant text files, especially | scripts and startup resource files. This is a porter "cop out", forcing | the user to deal with the \r for the porter. | | It is rather easy for the porter to fix the source code by supplying the | appropriate file processing mode switches to the open/fopen functions. | Treat all text files as text and treat all binary files as binary. To be | specific, you can select binary mode by adding O_BINARY to the second | argument of an open call, or "b" to second argument of an fopen call. | You can also call setmode (fd, O_BINARY). I think Octave does this part already. The problem is the use of ftell/fseek to reposition the file pointer in a text file. If we can't assume that that will work, then we have to come up with a different solution for reading these kinds of data files in Octave. I think this problem only happens in a few places, so perhaps it will not be too hard to fix. 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 -------------------------------------------------------------