«

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

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.

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

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

In <ab0dc9f6-1432-4b00-b8db-> 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"

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

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

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

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) kst- <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"