lex@cc.gatech.edu wrote: ....
UNLESS, the user is dealing with file positions. If the external file has CRLF's in it, then a single character internally can become two characters externally. So what should happen to "the" file position?
One answer, the way it is done right now, is to let "the position" jump by more than 1. This is basically what ANSI C does with text files. Another answer, would be to calculate a "virtual position" and map that back and forth to the actual file. This can require reading the entire beginnig of a file, though, and sucks for large files. It's very clean though.
Or yet another answer, is to simply disable messing with file positions for ascii files. If you really care about file positions, then maybe you are dealing with a binary file that happens to contain text?
I'd support the first alternative with the reasoning that file positions for ASCII files should be treated as opaque 'cookies', that is, you can get the file position and set it to get back to a point where you were before, but you should not do arithmetic with them. Everything else makes dealing with text files painful. Either you pay by waiting a long time for the mapping calculation, or you pay by inventing your own (probably buggy) file position handling.
Of course, the numbers that you remember and use to jump to a position in a file should not be kept when the file could possibly be manipulated by an outside entity, for example by some file transfer program that tries to be 'helpful' and inserts or deletes some 'bogus control characters'. Sadly, the changes file looks a lot like a text file although it is really a stupid database which must be treated as binary data...
Hans-Martin