file position *tell()* works different

[Tim Peters]

[Peter Abel]
> I'm working under W2k with
> Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on
> win32
>
> I have a file *test_data.txt* with the following content:
> 0123456789
> 0123456789
> abcdefghi
> ABCDEFGHIJKLMNOPQ
>
> and I work on it with the following python script:
>
> # Open NOT in binary mode
> fp=file('test_data.txt','r')
> a='xx'
> while a:
>   print 'Filepointer: %3d' %  fp.tell()
>   a=fp.readline()
> fp.close()
>
> print
>
> # Open IN binary mode
> fp=file('test_data.txt','r+b')
> a='xx'
> while a:
>   print 'Filepointer: %3d' %  fp.tell()
>   a=fp.readline()
> fp.close()
>
> Now, when test_data.txt is saved in PC-mode with 0xC, 0xA as newline
>it works correct.

What does "correct" mean?  Or what does incorrect mean?


> But when I save the file in UNIX-Mode with 0xA as newline,
> my script gives me the following output, where that one with
> the file not opened in binary mode is wrong:
> Filepointer:   0
> Filepointer:   7
> Filepointer:  19
> Filepointer:  30
> Filepointer:  49
> Filepointer:  51
>
> Filepointer:   0
> Filepointer:  11
> Filepointer:  22
> Filepointer:  32
> Filepointer:  50
> Filepointer:  51

What exactly about that do you think is wrong?  For example, tell() results
for files opened in text mode have no portably defined relationship to byte
offsets from the beginning of file, so it's not wrong simply that the
numbers displayed differ between the two blocks of output.  Here from the C
standard:

    The ftell function obtains the current value of the file position
    indicator for the stream pointed to by stream.  For a binary stream,
    the value is the number of characters from the beginning of the file.
    For a text stream, its file position indicator contains
    unspecified information, usable by the fseek function for returning
    the file position indicator for the stream to its position at the
    time of the ftell call; the difference between two such return
    values is not necessarily a meaningful measure of the number of
    characters written or read.

When f is opened in text mode, about the only thing you can do with an
f.tell() result portably is to use it as-is (without doing arithmetic on it
first) as an argument to a later f.seek().  When the standard says it's
unspecified beyond that, it means it.

> When I try this under HP-UX it works fine in both cases.

Unixish systems make no distinction between text mode and binary mode, but
Windows does.  That's why the results differ.

> So I wonder if the function *tell()* is not correctly implemented
> under win32.

Python's file.tell() on Windows just calls a Microsoft C function.  AFAIK,
Microsoft's implementation conforms to the C standard, but the C standard
doesn't promise as much as you appear to believe it does/should.