Unexpected tell() result

[Dan Wilga]

I'm seeing odd results when tell() is performed right after open with
append:

#!/usr/bin/perl -w
use strict;

open( FOO, ">foo" ) || die;
print FOO "test";
close FOO;

open( FOO, ">>foo" ) || die;
print "-s: ".(-s "foo")."\n";
print "tell: ".(tell FOO)."\n";
close FOO;

unlink( "foo" ) || die;


Under RedHat 7.1 (perl 5.8.0, glibc-2.2.4-32) I get:

-s: 4
tell: 4

which is what I expect. A Tru64 machine also returns these values.

However, under RedHat 8.0 (perl 5.8.0, glibc-2.3.2-4.80.8) I get:

-s: 4
tell: 0

Perl on the RH 8 system is not the RedHat rpm; it is compiled from
scratch. I get the same (bad) results with RH 9 and glibc-2.3.2-27.9.7.

Since the same version of Perl gives different results, I suspect a
glibc bug. Can anyone confirm this?

Is there a compile-time option that would avoid this?

 

[Ben Morrow]

I'm seeing odd results when tell() is performed right after open with
append:

Under RedHat 7.1 (perl 5.8.0, glibc-2.2.4-32) I get:

-s: 4
tell: 4

which is what I expect. A Tru64 machine also returns these values.

However, under RedHat 8.0 (perl 5.8.0, glibc-2.3.2-4.80.8) I get:

-s: 4
tell: 0

Since the same version of Perl gives different results, I suspect a
glibc bug. Can anyone confirm this?

I get the same results on Gentoo, perl 5.8.0, glibc 2.3.2, gcc 3.2.3,
linux 2.4.19.

A further demonstration that this behaviour is actually wrong:

% perl -wle'open my $O, ">foo" or die $!; print $O "foo"; close $O; \
open $O, ">>foo" or die $!; print $O "bar"; print tell $O'
4
%

despite the fact that 'bar' ends at position 8 in the file.

Ben

 

[Malcolm Dew-Jones]

Dan Wilga ([email protected]) wrote:
: I'm seeing odd results when tell() is performed right after open with
: append:

: #!/usr/bin/perl -w
: use strict;

: open( FOO, ">foo" ) || die;
: print FOO "test";
: close FOO;

: open( FOO, ">>foo" ) || die;
: print "-s: ".(-s "foo")."\n";
: print "tell: ".(tell FOO)."\n";
: close FOO;

: unlink( "foo" ) || die;


: Under RedHat 7.1 (perl 5.8.0, glibc-2.2.4-32) I get:

: -s: 4
: tell: 4

: which is what I expect. A Tru64 machine also returns these values.

: However, under RedHat 8.0 (perl 5.8.0, glibc-2.3.2-4.80.8) I get:

: -s: 4
: tell: 0

You've opend the file in append mode, so any write is supposed to go to
the end of the file, whereever that happens to be. However, the size of
the file could be changing due to another process, so the value of tell
that you read at one moment doesn't really have any relation to where the
data gets written.


I think the only question is whether a print to the handle writes the data
to the correct location in the file.

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(e-mail address removed) (Malcolm Dew-Jones) wrote in

Dan Wilga ([email protected]) wrote:
: I'm seeing odd results when tell() is performed right after open with
: append: ....
You've opend the file in append mode, so any write is supposed to go
to the end of the file, whereever that happens to be. However, the
size of the file could be changing due to another process, so the
value of tell that you read at one moment doesn't really have any
relation to where the data gets written.

Are you suggesting that some other process is writing to Dan's "foo" file
in the millisecond between its creation and his call to tell()?

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP8SbW2PeouIeTNHoEQL+ygCg1DvH2pFCRIje8dhLbPvQulrwTcQAniMH
3Kzwo4rwlhw9UrbdBchxE1WP
=vem/
-----END PGP SIGNATURE-----

 

[Dan Wilga]

You've opend the file in append mode, so any write is supposed to go to
the end of the file, whereever that happens to be. However, the size of
the file could be changing due to another process, so the value of tell
that you read at one moment doesn't really have any relation to where the
data gets written.

My process is the only one writing to the file. It actually doesn't
matter if I reopen the file immediately after creating it or two days
later, the result is the same.

 

[Brian McCauley]

Since the same version of Perl gives different results, I suspect a
glibc bug. Can anyone confirm this?

Personally I'd expect the behaviour of tell() on a file handle that's
in append mode but to which the last operation was not a write() by
the current process to be undefined.

If the behaviour is undefined the fact that different libc give
different results does not imply that either has a bug.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Ben Morrow]

Personally I'd expect the behaviour of tell() on a file handle that's
in append mode but to which the last operation was not a write() by
the current process to be undefined.

If the behaviour is undefined the fact that different libc give
different results does not imply that either has a bug.

It seems that under glibc 2.3 a file opened in append mode will read
from the current file position, but writes always go to the end and do
not move that position. Even straight after a write, the file pointer
is still at the beginning: pointing at the next byte to be read.

Ben

 

[Brian McCauley]

It seems that under glibc 2.3 a file opened in append mode will read
from the current file position, but writes always go to the end and do
not move that position. Even straight after a write, the file pointer
is still at the beginning: pointing at the next byte to be read.

Yeah, now you describe it that does sound like "the right thing". But
not so much so that all other behaviour could be considered "the wrong
thing".

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Malcolm Dew-Jones]

Eric J. Roode ([email protected]) wrote:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1

: (e-mail address removed) (Malcolm Dew-Jones) wrote in
:
: > Dan Wilga ([email protected]) wrote:
: >: I'm seeing odd results when tell() is performed right after open with
: >: append:
: ...
: > You've opend the file in append mode, so any write is supposed to go
: > to the end of the file, whereever that happens to be. However, the
: > size of the file could be changing due to another process, so the
: > value of tell that you read at one moment doesn't really have any
: > relation to where the data gets written.

: Are you suggesting that some other process is writing to Dan's "foo" file
: in the millisecond between its creation and his call to tell()?

No, I'm just suggesting (after thinking about various possible scenarios)
that there is no reason to expect the value of tell to have any particular
value when the file is opened in append mode.

Therefore, as long as the write works, then the value of tell can be
anything the system finds convenient. Some systems may always define a
pointer whenever any file is opened, and so tell has a value. Some
systems may avoid setting up a position pointer unless they need to, and
since append doesn't require it then the pointer isn't setup. Either
method would be correct.

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(e-mail address removed) (Malcolm Dew-Jones) wrote in

No, I'm just suggesting (after thinking about various possible
scenarios) that there is no reason to expect the value of tell to have
any particular value when the file is opened in append mode.

Oh right, of course. tell() only makes sense on files that are opened for
read.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP8VbuGPeouIeTNHoEQK9AACfaehEJzLF5GZGnpLwd8L+weiZE+cAnRzy
19VDc9lqZg5FzkSX2G3X5jcF
=hetK
-----END PGP SIGNATURE-----

 

[Malcolm Dew-Jones]

Eric J. Roode ([email protected]) wrote:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1

: (e-mail address removed) (Malcolm Dew-Jones) wrote in
:
: > No, I'm just suggesting (after thinking about various possible
: > scenarios) that there is no reason to expect the value of tell to have
: > any particular value when the file is opened in append mode.

: Oh right, of course. tell() only makes sense on files that are opened for
: read.

or regular write mode, because the write is going to occur at the current
file pointer location.

 

[Dan Wilga]

It seems that under glibc 2.3 a file opened in append mode will read
from the current file position, but writes always go to the end and do
not move that position. Even straight after a write, the file pointer
is still at the beginning: pointing at the next byte to be read.

Yeah, now you describe it that does sound like "the right thing". But
not so much so that all other behaviour could be considered "the wrong
thing".[/QUOTE]

Then this begs the question: Should Perl account for the fact that this
code behaves differently on different versions of glibc? Shouldn't Perl
work the same, independent of glibc version?

 

[Brian McCauley]

Yeah, now you describe it that does sound like "the right thing". But
not so much so that all other behaviour could be considered "the wrong
thing".

Then this begs the question: Should Perl account for the fact that this
code behaves differently on different versions of glibc? Shouldn't Perl
work the same, independent of glibc version?[/QUOTE]

No I don't think so - this is sufficiently obscure that I don't think
it really matters.

Incidently, looking at open() in the single Unix specification V3 it
would appear "the right thing" is not actually conformant with SUS3.

I'd be more inclined to see this as carelessness in the drafting of
SUS3 than a bug in glibc.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\