Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Matthew Danish mrd+nospam@cmu.edu writes:
This quick hack counts the number of carriage returns that need to be subtracted from the file-position. It runs quickly enough on large (15msec to count CRs for 4481 lines in a file I am testing) files that I think it should be acceptable, unless someone has a better idea. I don't know if 7.0 has this problem as well; if not then this could be conditionalized.
The problem is the same with 7.0 if I open a file with DOS-style eol-conversion. At least on Linux. The Allegro manual says something about #\newline#\linefeed -> #newline conversion under Windows, but I didn't understand when exactly it is used. Let's use your patch until somebody encounters a real problem.
Well I'm pretty sure that what is happening is that READ-CHAR is doing the necessary transformation on the input stream to convert #\return#\linefeed to #\newline, but the source file recording mechanism is using FILE-POSITION to record the location of the form. If you run a simple test like this:
(defun test (file) (with-open-file (stream file :direction :input) (loop for char = (read-char stream nil nil) while char do (format t "~S ~S~%" char (file-position stream)))))
Then you will see that the file-position advances twice everytime #\Newline is encountered. The entry for FILE-POSITION in the Allegro documentation seems to indicate this as well.