lex at 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