Unexpected tell() result

Discussion in 'Perl Misc' started by Dan Wilga, Nov 25, 2003.

  1. Dan Wilga

    Dan Wilga Guest

    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?

    --
    Dan Wilga
    ** Remove the -MUNGE in my address to reply **
    Dan Wilga, Nov 25, 2003
    #1
    1. Advertising

  2. Dan Wilga

    Ben Morrow Guest

    Dan Wilga <> wrote:
    > I'm seeing odd results when tell() is performed right after open with
    > append:
    >

    <snip>
    > 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
    >

    <snip>
    > 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

    --
    Although few may originate a policy, we are all able to judge it.
    - Pericles of Athens, c.430 B.C.
    Ben Morrow, Nov 25, 2003
    #2
    1. Advertising

  3. Dan Wilga () 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.
    Malcolm Dew-Jones, Nov 25, 2003
    #3
  4. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    (Malcolm Dew-Jones) wrote in
    news::

    > Dan Wilga () 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-----
    Eric J. Roode, Nov 26, 2003
    #4
  5. Dan Wilga

    Dan Wilga Guest

    In article <>,
    (Malcolm Dew-Jones) wrote:

    > 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.

    --
    Dan Wilga
    ** Remove the -MUNGE in my address to reply **
    Dan Wilga, Nov 26, 2003
    #5
  6. Dan Wilga <> writes:

    > 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\\
    Brian McCauley, Nov 26, 2003
    #6
  7. Dan Wilga

    Ben Morrow Guest

    Brian McCauley <> wrote:
    > Dan Wilga <> writes:
    >
    > > 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.


    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

    --
    For the last month, a large number of PSNs in the Arpa[Inter-]net have been
    reporting symptoms of congestion ... These reports have been accompanied by an
    increasing number of user complaints ... As of June,... the Arpanet contained
    47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *
    Ben Morrow, Nov 26, 2003
    #7
  8. Ben Morrow <> writes:

    > Brian McCauley <> wrote:
    > > Dan Wilga <> writes:
    > >
    > > > 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.

    >
    > 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\\
    Brian McCauley, Nov 26, 2003
    #8
  9. Eric J. Roode () wrote:
    : -----BEGIN PGP SIGNED MESSAGE-----
    : Hash: SHA1

    : (Malcolm Dew-Jones) wrote in
    : news::

    : > Dan Wilga () 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.
    Malcolm Dew-Jones, Nov 26, 2003
    #9
  10. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    (Malcolm Dew-Jones) wrote in
    news::

    > 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-----
    Eric J. Roode, Nov 27, 2003
    #10
  11. Eric J. Roode () wrote:
    : -----BEGIN PGP SIGNED MESSAGE-----
    : Hash: SHA1

    : (Malcolm Dew-Jones) wrote in
    : news::

    : > 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.
    Malcolm Dew-Jones, Nov 27, 2003
    #11
  12. Dan Wilga

    Dan Wilga Guest

    In article <>,
    Brian McCauley <> wrote:

    > > 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".


    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?

    --
    Dan Wilga
    ** Remove the -MUNGE in my address to reply **
    Dan Wilga, Dec 2, 2003
    #12
  13. Dan Wilga <> writes:

    > In article <>,
    > Brian McCauley <> wrote:
    >
    > > > 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".

    >
    > 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?


    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\\
    Brian McCauley, Dec 2, 2003
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Pemberton

    unexpected result using std::list

    Mike Pemberton, Oct 14, 2003, in forum: C++
    Replies:
    3
    Views:
    342
    Dan Cernat
    Oct 14, 2003
  2. yogesh
    Replies:
    1
    Views:
    364
    Victor Bazarov
    Mar 14, 2007
  3. Michael Tan
    Replies:
    32
    Views:
    955
    Ara.T.Howard
    Jul 21, 2005
  4. Andy Tolle
    Replies:
    7
    Views:
    227
    Andy Tolle
    Nov 15, 2010
  5. Mike A
    Replies:
    17
    Views:
    259
    Dr John Stockton
    Nov 19, 2003
Loading...

Share This Page