Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23781 > unrolled thread

fseek

Back to article view | Back to comp.lang.c

Contents

  fseek Bill Cunningham <billcun@suddenlink.net> - 2012-07-26 19:22 -0700
    Re: fseek cartec69@gmail.com - 2012-07-26 20:46 -0700
      Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-26 23:15 -0500
    Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-26 23:13 -0500
      Re: fseek James Kuyper <jameskuyper@verizon.net> - 2012-07-27 07:20 -0400
        Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-27 12:52 -0500
          Re: fseek Keith Thompson <kst-u@mib.org> - 2012-07-27 16:11 -0700
            Re: fseek Keith Thompson <kst-u@mib.org> - 2012-07-27 16:54 -0700
              Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-27 23:10 -0500
                Re: fseek James Kuyper <jameskuyper@verizon.net> - 2012-07-28 11:25 -0400
                Re: fseek Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 17:02 +0100
                  Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-28 11:39 -0500
                    Re: fseek Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 17:58 +0100
                      Re: fseek Les Cargill <lcargill99@comcast.com> - 2012-07-28 16:07 -0500
                        Re: fseek Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 22:30 +0100
    Re: fseek John Gordon <gordon@panix.com> - 2012-07-27 05:26 +0000
    Re: fseek gordonb.rclzu@burditt.org (Gordon Burditt) - 2012-07-27 12:30 -0500
      Re: fseek Bill Cunningham <billcun@suddenlink.net> - 2012-07-27 15:36 -0700
      Re: fseek Bill Cunningham <billcun@suddenlink.net> - 2012-07-27 15:36 -0700

#23781 — fseek

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

[toc] | [next] | [standalone]

#23782

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.

[toc] | [prev] | [next] | [standalone]

#23784

cartec69@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#23783

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

[toc] | [prev] | [next] | [standalone]

#23793

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

[toc] | [prev] | [next] | [standalone]

#23801

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

[toc] | [prev] | [next] | [standalone]

#23828

Les Cargill <lcargill99@comcast.com> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#23833

Keith Thompson <kst-u@mib.org> writes:
> Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#23836

Keith Thompson wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> 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

[toc] | [prev] | [next] | [standalone]

#23849

On 07/28/2012 12:10 AM, Les Cargill wrote:
> Keith Thompson wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> 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

[toc] | [prev] | [next] | [standalone]

#23851

Les Cargill <lcargill99@comcast.com> 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.

[toc] | [prev] | [next] | [standalone]

#23853

Ben Bacarisse wrote:
> Les Cargill <lcargill99@comcast.com> 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

[toc] | [prev] | [next] | [standalone]

#23855

Les Cargill <lcargill99@comcast.com> writes:

> Ben Bacarisse wrote:
>> Les Cargill <lcargill99@comcast.com> 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.

[toc] | [prev] | [next] | [standalone]

#23858

Ben Bacarisse wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> Ben Bacarisse wrote:
>>> Les Cargill <lcargill99@comcast.com> 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

[toc] | [prev] | [next] | [standalone]

#23859

Les Cargill <lcargill99@comcast.com> writes:

> Ben Bacarisse wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> Ben Bacarisse wrote:
>>>> Les Cargill <lcargill99@comcast.com> 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.

[toc] | [prev] | [next] | [standalone]

#23786

In <ab0dc9f6-1432-4b00-b8db-a68d3b14f6a9@googlegroups.com> Bill Cunningham <billcun@suddenlink.net> writes:

> This compiles fine and prints nothing.

Does the program ever finish?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#23799

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

> 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 

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 this code 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?  Are those two the same place?

> Or is there a problem with printf?

There's a problem with the way you called it.

[toc] | [prev] | [next] | [standalone]

#23826

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 is the 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. > 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 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 this code 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? Are those 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

[toc] | [prev] | [next] | [standalone]

#23827

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 is the 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. > 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 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 this code 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? Are those 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web