fseek

Discussion in 'C Programming' started by Bill Cunningham, Jul 27, 2012.

  1. This seems like a simple enough question that it shouldn't be too difficultin clc discussion. If the discussion would turn to learning or teaching. Iwant to allocate enough memory to hold a whole file. malloc is of course going to be needed so I think fseek is the way to learn how big a file is. Itried this and the code compiled find and displayed nothing so I'm at a loss as to what happened. I deleted the source code so I will make referencesto it.

    #include <stdio.h>

    FILE *fp;
    if ((fp=fopen("j","rb"))==NULL)
    perror("fopen 1 error");
    long l;
    while(!feof(fp))
    l=fseek(fp,0,SEEK_SET);
    fclose(fp);
    printf("%d\n%d\n",l,ftell(fp));
    }

    This compiles fine and prints nothing. Did the file pointer move? Or is there a problem with printf?

    Bill
     
    Bill Cunningham, Jul 27, 2012
    #1
    1. Advertising

  2. Bill Cunningham

    Guest

    On Thursday, July 26, 2012 9:22:22 PM UTC-5, Bill Cunningham wrote:
    > l=fseek(fp,0,SEEK_SET);


    You are instructing the file (fp) to seek to a position 0 bytes away from the
    current position (SEEK_SET). It's effectively a no-op that returns the current file position, which will always be zero since you've just opened the file and done nothing with it. If the file size is non-zero, the while loop will never terminate.
     
    , Jul 27, 2012
    #2
    1. Advertising

  3. Bill Cunningham

    Les Cargill Guest

    Bill Cunningham wrote:
    > This seems like a simple enough question that it shouldn't be too difficult in clc discussion. If the discussion would turn to learning or teaching. I want to allocate enough memory to hold a whole file. malloc is of course going to be needed so I think fseek is the way to learn how big a file is. I tried this and the code compiled find and displayed nothing so I'm at a loss as to what happened. I deleted the source code so I will make references to it.
    >
    > #include <stdio.h>
    >
    > FILE *fp;
    > if ((fp=fopen("j","rb"))==NULL)
    > perror("fopen 1 error");
    > long l;


    You don't really need the eof check
    nor the "while..." Just call fseek().

    > while(!feof(fp))
    > l=fseek(fp,0,SEEK_SET);


    you're close. Try
    l=fseek(fp,0,SEEK_END);

    That will at least get you to the next bug.

    And can I buy you some indentation? :) Good
    habit to develop.

    > fclose(fp);


    Closing a file and then calling eof is at the
    very least bad form.

    > printf("%d\n%d\n",l,ftell(fp));
    > }
    >
    > This compiles fine and prints nothing. Did the file pointer move? Or is there a problem with printf?
    >
    > Bill
    >


    #include <stdio.h>
    #include <assert.h>

    int main(void)
    {
    FILE *fp;
    fp=fopen("j","rb");
    assert(fp);

    long l = fseek(fp,0L,SEEK_END);
    assert(l==0);

    printf("l=%d\nFile size is %d\n",l,ftell(fp));

    fclose(fp);

    return 1;
    }


    --
    Les Cargill
     
    Les Cargill, Jul 27, 2012
    #3
  4. Bill Cunningham

    Les Cargill Guest

    wrote:
    > On Thursday, July 26, 2012 9:22:22 PM UTC-5, Bill Cunningham wrote:
    >> l=fseek(fp,0,SEEK_SET);

    >
    > You are instructing the file (fp) to seek to a position 0 bytes away
    > from the current position (SEEK_SET).



    SEET_SET is relative to the beginning of the file. SEEK_CUR is relative
    to the current position. SEEK_END is relative to the end.

    It's effectively a no-op that
    > returns the current file position, which will always be zero since
    > you've just opened the file and done nothing with it. If the file
    > size is non-zero, the while loop will never terminate.
    >


    That's true.

    --
    Les Cargill
     
    Les Cargill, Jul 27, 2012
    #4
  5. Bill Cunningham

    John Gordon Guest

    In <> Bill Cunningham <> writes:

    > This compiles fine and prints nothing.


    Does the program ever finish?

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Jul 27, 2012
    #5
  6. Bill Cunningham

    James Kuyper Guest

    On 07/27/2012 12:13 AM, Les Cargill wrote:
    ....
    > #include <stdio.h>
    > #include <assert.h>
    >
    > int main(void)
    > {
    > FILE *fp;
    > fp=fopen("j","rb");
    > assert(fp);
    >
    > long l = fseek(fp,0L,SEEK_END);


    While that will often do precisely what you're expecting it to do, "A
    binary stream need not meaningfully support fseek calls with a whence
    value of SEEK_END." (7.21.9.2p3)
    --
    James Kuyper
    n
     
    James Kuyper, Jul 27, 2012
    #6
  7. Bill Cunningham

    Les Cargill Guest

    James Kuyper wrote:
    > On 07/27/2012 12:13 AM, Les Cargill wrote:
    > ...
    >> #include <stdio.h>
    >> #include <assert.h>
    >>
    >> int main(void)
    >> {
    >> FILE *fp;
    >> fp=fopen("j","rb");
    >> assert(fp);
    >>
    >> long l = fseek(fp,0L,SEEK_END);

    >
    > While that will often do precisely what you're expecting it to do, "A
    > binary stream need not meaningfully support fseek calls with a whence
    > value of SEEK_END." (7.21.9.2p3)
    >


    Wow - didn't know that. Thanks! Hopefully, it returns a nonzero
    when it does not apply to that stream.

    --
    Les Cargill
     
    Les Cargill, Jul 27, 2012
    #7
  8. On Friday, July 27, 2012 1:30:40 PM UTC-4, Gordon Burditt wrote:
    > > This seems like a simple enough question that it shouldn't be too > difficult in clc discussion. If the discussion would turn to learning > or teaching. I want to allocate enough memory to hold a whole file. Beware that the file might grow between getting the size of it and reading it in. This is common with log files. Do not read more file than the size of the memory you allocated. > malloc is of course going to be needed so I think fseek isthe way > to learn how big a file is. That works for binary files (which you are using), not for text files. Seeking to the end of a binary file (which you don't attempt) is also not guaranteed to work. There are many varying definitions of what "the size of a file" is, often with different values,although you seem to be using "the amount of memory I need to read in the whole file", which is fine as long as the file doesn't change size at the wrong time. It also gives you the size the file used to be, not necessarily the size it is by the time you get the result and do something with it. > Itried this and the code compiled find > and displayed nothing so I'm at a loss as to what happened. > I deleted > the source code Why did you delete the source code if you are going to ask for help with it? > so I will make references to it. > > #include <stdio.h> > > FILE *fp; You need to put thiscode in a function, such as main(). > if ((fp=fopen("j","rb"))==NULL) > perror("fopen 1 error"); The indentation style for the above statement is terrible and misleading. If the file failed to open, do you really want to continue the program here? Or should you exit once you have printed the error message above? > long l; > while(!feof(fp)) > l=fseek(fp,0,SEEK_SET); The indentation style for the above statement is terrible and misleading.. This rewinds the file to the beginning. Is this what you intended? Why? >fclose(fp); feof() returns true after you tried to read data and got EOF instead. Does that ever happen? Why should you ever exit the while() loop? Do you think a never-ending while loop might be the reason you never got to the printf() call below? Here you called ftell(fp) *AFTER* you closed fp. Do you see a problem with this? You should. > printf("%d\n%d\n",l,ftell(fp)); What is the return type of ftell()? What is the type of the variable l declared above? What printf() conversion goes with that type? Why didn't you use it instead of %d? > } > > This compiles fine and prints nothing. You should turn up the warnings on your compiler, although that may not find the main problem with your code. > Did the file pointer move? Did you *ask* it to move? Where was it when the file was opened? Where did you fseek to? Arethose two the same place? > Or is there a problem with printf? There's a problem with the way you called it.


    Thanks for your input Gordon it is appreciated.

    Bill
     
    Bill Cunningham, Jul 27, 2012
    #8
  9. On Friday, July 27, 2012 1:30:40 PM UTC-4, Gordon Burditt wrote:
    > > This seems like a simple enough question that it shouldn't be too > difficult in clc discussion. If the discussion would turn to learning > or teaching. I want to allocate enough memory to hold a whole file. Beware that the file might grow between getting the size of it and reading it in. This is common with log files. Do not read more file than the size of the memory you allocated. > malloc is of course going to be needed so I think fseek isthe way > to learn how big a file is. That works for binary files (which you are using), not for text files. Seeking to the end of a binary file (which you don't attempt) is also not guaranteed to work. There are many varying definitions of what "the size of a file" is, often with different values,although you seem to be using "the amount of memory I need to read in the whole file", which is fine as long as the file doesn't change size at the wrong time. It also gives you the size the file used to be, not necessarily the size it is by the time you get the result and do something with it. > Itried this and the code compiled find > and displayed nothing so I'm at a loss as to what happened. > I deleted > the source code Why did you delete the source code if you are going to ask for help with it? > so I will make references to it. > > #include <stdio.h> > > FILE *fp; You need to put thiscode in a function, such as main(). > if ((fp=fopen("j","rb"))==NULL) > perror("fopen 1 error"); The indentation style for the above statement is terrible and misleading. If the file failed to open, do you really want to continue the program here? Or should you exit once you have printed the error message above? > long l; > while(!feof(fp)) > l=fseek(fp,0,SEEK_SET); The indentation style for the above statement is terrible and misleading.. This rewinds the file to the beginning. Is this what you intended? Why? >fclose(fp); feof() returns true after you tried to read data and got EOF instead. Does that ever happen? Why should you ever exit the while() loop? Do you think a never-ending while loop might be the reason you never got to the printf() call below? Here you called ftell(fp) *AFTER* you closed fp. Do you see a problem with this? You should. > printf("%d\n%d\n",l,ftell(fp)); What is the return type of ftell()? What is the type of the variable l declared above? What printf() conversion goes with that type? Why didn't you use it instead of %d? > } > > This compiles fine and prints nothing. You should turn up the warnings on your compiler, although that may not find the main problem with your code. > Did the file pointer move? Did you *ask* it to move? Where was it when the file was opened? Where did you fseek to? Arethose two the same place? > Or is there a problem with printf? There's a problem with the way you called it.


    Thanks for your input Gordon it is appreciated.

    Bill
     
    Bill Cunningham, Jul 27, 2012
    #9
  10. Les Cargill <> writes:
    > James Kuyper wrote:


    Not necessarily.

    N1570 7.21.2p3:

    A binary stream is an ordered sequence of characters that can
    transparently record internal data. Data read in from a binary
    stream shall compare equal to the data that were earlier written
    out to that stream, under the same implementation. Such a stream
    may, however, have an implementation-defined number of null
    characters appended to the end of the stream.

    For example, a system might only support binary files consisting of a
    whole number of fixed-size blocks.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jul 28, 2012
    #10
  11. Keith Thompson <> writes:
    > Les Cargill <> writes:
    >> James Kuyper wrote:

    >
    > Not necessarily.
    >
    > N1570 7.21.2p3:
    >
    > A binary stream is an ordered sequence of characters that can
    > transparently record internal data. Data read in from a binary
    > stream shall compare equal to the data that were earlier written
    > out to that stream, under the same implementation. Such a stream
    > may, however, have an implementation-defined number of null
    > characters appended to the end of the stream.
    >
    > For example, a system might only support binary files consisting of a
    > whole number of fixed-size blocks.


    Whoops, I goofed when trimming the quoted text. Here's the context I
    *meant* to quote:

    Les Cargill <> writes:
    > James Kuyper wrote:

    [...]
    >> While that will often do precisely what you're expecting it to do, "A
    >> binary stream need not meaningfully support fseek calls with a whence
    >> value of SEEK_END." (7.21.9.2p3)
    >>

    >
    > Wow - didn't know that. Thanks! Hopefully, it returns a nonzero
    > when it does not apply to that stream.


    ....

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jul 28, 2012
    #11
  12. Bill Cunningham

    Les Cargill Guest

    Keith Thompson wrote:
    > Keith Thompson <> writes:
    >> Les Cargill <> writes:
    >>> James Kuyper wrote:

    >>
    >> Not necessarily.
    >>
    >> N1570 7.21.2p3:
    >>
    >> A binary stream is an ordered sequence of characters that can
    >> transparently record internal data. Data read in from a binary
    >> stream shall compare equal to the data that were earlier written
    >> out to that stream, under the same implementation. Such a stream
    >> may, however, have an implementation-defined number of null
    >> characters appended to the end of the stream.
    >>
    >> For example, a system might only support binary files consisting of a
    >> whole number of fixed-size blocks.

    >
    > Whoops, I goofed when trimming the quoted text. Here's the context I
    > *meant* to quote:
    >
    > Les Cargill <> writes:
    >> James Kuyper wrote:

    > [...]
    >>> While that will often do precisely what you're expecting it to do, "A
    >>> binary stream need not meaningfully support fseek calls with a whence
    >>> value of SEEK_END." (7.21.9.2p3)
    >>>

    >>
    >> Wow - didn't know that. Thanks! Hopefully, it returns a nonzero
    >> when it does not apply to that stream.

    >
    > ...
    >


    James, I have been programming in 'C'... perhaps longer than
    I should have, and I have never come across a device that would not
    feeek(...,SEEK_END) exactly as one would expect it would.

    I remember nine-track tape too, but I wasn't doing *that* in 'C'.

    Yadda, yadda, etc, esp ipsioders infinitum. :)

    :)

    (it even works on USB! Sacre mirablieu!!)

    --
    Les Cargill
     
    Les Cargill, Jul 28, 2012
    #12
  13. Bill Cunningham

    James Kuyper Guest

    On 07/28/2012 12:10 AM, Les Cargill wrote:
    > Keith Thompson wrote:
    >> Keith Thompson <> writes:
    >>> Les Cargill <> writes:
    >>>> James Kuyper wrote:
    >>>
    >>> Not necessarily.
    >>>
    >>> N1570 7.21.2p3:
    >>>
    >>> A binary stream is an ordered sequence of characters that can
    >>> transparently record internal data. Data read in from a binary
    >>> stream shall compare equal to the data that were earlier written
    >>> out to that stream, under the same implementation. Such a stream
    >>> may, however, have an implementation-defined number of null
    >>> characters appended to the end of the stream.
    >>>
    >>> For example, a system might only support binary files consisting of a
    >>> whole number of fixed-size blocks.

    >>
    >> Whoops, I goofed when trimming the quoted text. Here's the context I
    >> *meant* to quote:
    >>
    >> Les Cargill <> writes:
    >>> James Kuyper wrote:

    >> [...]
    >>>> While that will often do precisely what you're expecting it to do, "A
    >>>> binary stream need not meaningfully support fseek calls with a whence
    >>>> value of SEEK_END." (7.21.9.2p3)
    >>>>
    >>>
    >>> Wow - didn't know that. Thanks! Hopefully, it returns a nonzero
    >>> when it does not apply to that stream.

    >>
    >> ...
    >>

    >
    > James, I have been programming in 'C'... perhaps longer than
    > I should have, and I have never come across a device that would not
    > feeek(...,SEEK_END) exactly as one would expect it would.


    As I said, "that will often do precisely what you're expecting it to
    do.". I didn't say how often, because I have no idea. I write my code to
    avoid relying upon anything that isn't guaranteed by the applicable
    standards, rather than trying to keep track of how common it is for the
    unguaranteed behavior to be what I might otherwise expect it to be.

    On my current project, where I've been working since 1996, the
    applicable standards are C90 plus the corresponding TCs, and a
    comparably out-dated version of POSIX, plus some project-specific
    standards that wouldn't be meaningful to you. I believe that POSIX does
    guarantee the behavior, at least when stream represents an actual file,
    rather than a device - but this group isn't about POSIX. stat() would be
    the more direct way of obtaining the same information, but it's use is
    prohibited by the project-specific standards mentioned above.
    --
    James Kuyper
     
    James Kuyper, Jul 28, 2012
    #13
  14. Les Cargill <> writes:
    <snip>
    > James, I have been programming in 'C'... perhaps longer than
    > I should have, and I have never come across a device that would not
    > feeek(...,SEEK_END) exactly as one would expect it would.


    Well, the "exactly as one would expect" makes the statement entirely
    dependent on what one expects! But for people with less experienced
    expectations, surprises are certainly possible. For example, fseek(...,
    SEEK_END) on an open FIFO will fail and there are other special files
    (at least on Linux) that are not seekable.

    Of course that's just things that you can't seek on. Other surprises
    include readable files (like /dev/zero) where seeking to the end gives a
    position of 0. You can seek -1000 bytes back from the end if you like
    and you'll be still at file position 0.

    And some people are surprised that you can seek beyond the end of plain
    file, even when it is opened only for reading.

    --
    Ben.
     
    Ben Bacarisse, Jul 28, 2012
    #14
  15. Bill Cunningham

    Les Cargill Guest

    Ben Bacarisse wrote:
    > Les Cargill <> writes:
    > <snip>
    >> James, I have been programming in 'C'... perhaps longer than
    >> I should have, and I have never come across a device that would not
    >> feeek(...,SEEK_END) exactly as one would expect it would.

    >
    > Well, the "exactly as one would expect" makes the statement entirely
    > dependent on what one expects! But for people with less experienced
    > expectations, surprises are certainly possible. For example, fseek(...,
    > SEEK_END) on an open FIFO will fail and there are other special files
    > (at least on Linux) that are not seekable.
    >


    Well, sure. But other than the sort of experimental learning we
    all do with a new system, there's probably not a compelling reason
    to call fseek() on a FIFO :)

    > Of course that's just things that you can't seek on. Other surprises
    > include readable files (like /dev/zero) where seeking to the end gives a
    > position of 0. You can seek -1000 bytes back from the end if you like
    > and you'll be still at file position 0.
    >
    > And some people are surprised that you can seek beyond the end of plain
    > file, even when it is opened only for reading.
    >


    --
    Les Cargill
     
    Les Cargill, Jul 28, 2012
    #15
  16. Les Cargill <> writes:

    > Ben Bacarisse wrote:
    >> Les Cargill <> writes:
    >> <snip>
    >>> James, I have been programming in 'C'... perhaps longer than
    >>> I should have, and I have never come across a device that would not
    >>> feeek(...,SEEK_END) exactly as one would expect it would.

    >>
    >> Well, the "exactly as one would expect" makes the statement entirely
    >> dependent on what one expects! But for people with less experienced
    >> expectations, surprises are certainly possible. For example, fseek(...,
    >> SEEK_END) on an open FIFO will fail and there are other special files
    >> (at least on Linux) that are not seekable.
    >>

    >
    > Well, sure. But other than the sort of experimental learning we
    > all do with a new system, there's probably not a compelling reason
    > to call fseek() on a FIFO :)


    But code will often seek a file (either given by name or one already
    open) with no idea what it is. When you use fseek in a program (and
    more so in a reusable function like read_whole_file) you are, in effect,
    making a compelling reason to call it on a FIFO because you can bet your
    users will do so eventually.

    If the OP decides that reading a whole file is best done with fseek,
    ftell and big a fread, then it won't work on some things (like FIFOs).
    Reading in chunks, and grow a buffer as you do so, will work on almost
    any file at the expense of some cost in allocations. For many cases,
    though, the file will be read in one or maybe two mouthfuls.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Jul 28, 2012
    #16
  17. Bill Cunningham

    Les Cargill Guest

    Ben Bacarisse wrote:
    > Les Cargill <> writes:
    >
    >> Ben Bacarisse wrote:
    >>> Les Cargill <> writes:
    >>> <snip>
    >>>> James, I have been programming in 'C'... perhaps longer than
    >>>> I should have, and I have never come across a device that would not
    >>>> feeek(...,SEEK_END) exactly as one would expect it would.
    >>>
    >>> Well, the "exactly as one would expect" makes the statement entirely
    >>> dependent on what one expects! But for people with less experienced
    >>> expectations, surprises are certainly possible. For example, fseek(...,
    >>> SEEK_END) on an open FIFO will fail and there are other special files
    >>> (at least on Linux) that are not seekable.
    >>>

    >>
    >> Well, sure. But other than the sort of experimental learning we
    >> all do with a new system, there's probably not a compelling reason
    >> to call fseek() on a FIFO :)

    >
    > But code will often seek a file (either given by name or one already
    > open) with no idea what it is. When you use fseek in a program (and
    > more so in a reusable function like read_whole_file) you are, in effect,
    > making a compelling reason to call it on a FIFO because you can bet your
    > users will do so eventually.
    >


    Hence the idiom:
    long l = fseek(fp,0L,SEEK_END);
    assert(l==0);


    It's a "toy" program or you'd need to do better cleanup than simply
    assert()-ing out.

    > If the OP decides that reading a whole file is best done with fseek,
    > ftell and big a fread, then it won't work on some things (like FIFOs).


    File size isn't a defined quantity for FIFOs.

    > Reading in chunks, and grow a buffer as you do so, will work on almost
    > any file at the expense of some cost in allocations. For many cases,
    > though, the file will be read in one or maybe two mouthfuls.
    >


    These days, I take it in one gulp usually - on a PC. And whoever
    said "use stat()" is probably correct.

    > <snip>
    >


    --
    Les Cargill
     
    Les Cargill, Jul 28, 2012
    #17
  18. Les Cargill <> writes:

    > Ben Bacarisse wrote:
    >> Les Cargill <> writes:
    >>
    >>> Ben Bacarisse wrote:
    >>>> Les Cargill <> writes:
    >>>> <snip>
    >>>>> James, I have been programming in 'C'... perhaps longer than
    >>>>> I should have, and I have never come across a device that would not
    >>>>> feeek(...,SEEK_END) exactly as one would expect it would.
    >>>>
    >>>> Well, the "exactly as one would expect" makes the statement entirely
    >>>> dependent on what one expects! But for people with less experienced
    >>>> expectations, surprises are certainly possible. For example, fseek(...,
    >>>> SEEK_END) on an open FIFO will fail and there are other special files
    >>>> (at least on Linux) that are not seekable.
    >>>>
    >>>
    >>> Well, sure. But other than the sort of experimental learning we
    >>> all do with a new system, there's probably not a compelling reason
    >>> to call fseek() on a FIFO :)

    >>
    >> But code will often seek a file (either given by name or one already
    >> open) with no idea what it is. When you use fseek in a program (and
    >> more so in a reusable function like read_whole_file) you are, in effect,
    >> making a compelling reason to call it on a FIFO because you can bet your
    >> users will do so eventually.

    >
    > Hence the idiom:
    > long l = fseek(fp,0L,SEEK_END);
    > assert(l==0);


    That's an odd idiom. I hope it is not as popular as the term "idiom"
    suggests. Why the "long"? Why use assert to test for an ordinary
    error? It seems all wrong to me.

    > It's a "toy" program or you'd need to do better cleanup than simply
    > assert()-ing out.


    Even toy programs can get compiled with NDEBUG defined, so I'd advise
    most strongly against error-checking using assert.

    >> If the OP decides that reading a whole file is best done with fseek,
    >> ftell and big a fread, then it won't work on some things (like FIFOs).

    >
    > File size isn't a defined quantity for FIFOs.


    No, and it's not that well-defined for plain files, either! Not only
    can files change but, if it's a text file, what you read might not be
    what's stored.

    Though size seems to have become the issue, the original problem was
    about storing the whole file, and that doesn't need the size up-front
    (though it helps, which is why people do it despite the down-side).

    >> Reading in chunks, and grow a buffer as you do so, will work on almost
    >> any file at the expense of some cost in allocations. For many cases,
    >> though, the file will be read in one or maybe two mouthfuls.

    >
    > These days, I take it in one gulp usually - on a PC. And whoever
    > said "use stat()" is probably correct.


    If the code is to be portable between systems, and the file is a text
    file, I'd be wary of any method that loses the line ending translation.
    Of course stat may be the way to go for the OP, but I don't feel I have
    enough information to make a sound choice.

    --
    Ben.
     
    Ben Bacarisse, Jul 28, 2012
    #18
    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. Leslaw Bieniasz

    How to speed up ftell()/fseek()

    Leslaw Bieniasz, Jun 6, 2005, in forum: C++
    Replies:
    7
    Views:
    4,835
    Lionel B
    Jun 8, 2005
  2. Christopher Benson-Manica

    fseek

    Christopher Benson-Manica, Nov 7, 2003, in forum: C Programming
    Replies:
    62
    Views:
    2,553
    Alan Balmer
    Nov 17, 2003
  3. TJ Walls

    fseek speed

    TJ Walls, Jul 27, 2004, in forum: C Programming
    Replies:
    16
    Views:
    1,359
    CBFalconer
    Aug 1, 2004
  4. Orion

    Determining EOF using fseek()?

    Orion, Aug 27, 2004, in forum: C Programming
    Replies:
    10
    Views:
    1,135
    Chris Torek
    Sep 5, 2004
  5. sieg1974

    string length questions related to fseek

    sieg1974, Sep 2, 2004, in forum: C Programming
    Replies:
    13
    Views:
    561
    Joe Wright
    Sep 4, 2004
Loading...

Share This Page