SIze of file

[munish.nr]

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

rgrds,
Munish Nayyar

[David Lee]

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

[David Resnick]

mu*******@gmail.com wrote:

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

rgrds,
Munish Nayyar

Have a look at the FAQ:

http://www.eskimo.com/~scs/C-faq/q19.12.html

-David

[Lew Pitcher]

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

mu*******@gmail.com wrote:

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

I can only think of two methods to determine file size that are consistant with
the C standard:

1) fopen() the file,
initialize an unsigned long (or longer) variable to 0
until fgetc() returns end of file, add 1 to the counter
fclose() the file,

or

2) fopen() the file
fseek() to the end of the file
ftell() the position of the end of the file
fclose() the file

Both of these methods have their drawbacks. Character counting may give
different results depending on whether the file was opened in binary or text
mode, and fseek()/ftell() may or may not work, depending on the implementation
("a binary stream need not meaningfully support fseek calls with a whence value
of SEEK_END" and ftell() return value is either the absolute position (when used
on a binary stream), or some "unspecified information" when used on a text stream).

Your choice.

- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFC+1XaagVFX4UWr64RAhyzAKCYNfPqV64rRBZ5p6SoxZ oJxMvp5gCg7C80
colQvhV5MvyjLy/zhrNDSgA=
=CstA
-----END PGP SIGNATURE-----

[Chris Dollin]

mu*******@gmail.com wrote:

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.

Tell us why you want to know the file size.

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Default User]

David Lee wrote:

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

Where are your definitions for off_t, stat, lstat?

Brian

[Keith Thompson]

"David Lee" <li*******@gmail.com> writes:

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

First, please provide some context when you post a followup. Search
for "google broken reply link" in this newsgroup for many many copies
of the same explanation.

Second, the type "struct stat" and the lstat function are not defined
in standard C, and are therefore off-topic in this newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

David Lee wrote:

Please quote what you are replying to. Check CBFalconer's sig for
instructions.

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

Standard C does not have lstat or any of the related functions,
therefore your solution of off topic here since we only deal with
standard C. Had the OP indicated s/he was using unix you could have
redirected him to a unix group suggesting that solution since there is
no standard C solution to the OP's stated problem.

Please also read the FAQ, Google will give it to you if you ask it.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Alexei A. Frounze]

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

mu*******@gmail.com wrote: .... Tell us why you want to know the file size.

Tell us what's wrong with such a desire? How about malloc'ing memory for the
entire file? How about comparing files (1st check being file size check)?
How about checking if there's enough space on some media to store it before
trying to store at all?

Alex

[Keith Thompson]

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

mu*******@gmail.com wrote:

...

Tell us why you want to know the file size.

Tell us what's wrong with such a desire? How about malloc'ing memory for the
entire file? How about comparing files (1st check being file size check)?
How about checking if there's enough space on some media to store it before
trying to store at all?

The answer could be different for each of those three reasons.

If you want to malloc memory for the entire file, how are you reading
it? The size may be different depending on whether you read it in
text or binary mode. If you're comparing files, the meaning of "size"
might differ depending on the type of file. And if you want to store
it on some media, you probably don't know how much overhead is going
to be imposed by the file system.

On a Unix-like system, seeking to the end of the file and calling
ftell() will very likely give you a meaningful answer, but this isn't
a Unix newsgroup. On other systems, there may not even be a
meaningful answer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[munish.nr]

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

i know only filename

so, is there any way to find the sizeof file in standard C ( so that
works on both platforms.)

also, the strcut lstat is vaild for unix, but is not standard c
compliant.

does anybody is having idea.?

Plz Help.

rgrds,
Munish Nayyar
emanshu "Innovative MInd"

[Alexei A. Frounze]

<mu*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

i know only filename

so, is there any way to find the sizeof file in standard C ( so that
works on both platforms.)

also, the strcut lstat is vaild for unix, but is not standard c
compliant.

does anybody is having idea.?

long fsize (const char* name)
{
long pos;
FILE* f=fopen(name,"rb");
if (!f) return -1;
if (!fseek(f,0,SEEK_END))
pos = ftell(f);
else
pos = -1;
fclose (f);
return pos;
}
That would be the most portable implementation.
Will work for file sizes up to ~2GB (due to long and FAT limitations).

Alex

[David Lee]

#include <sys/types.h>
#include <sys/stat.h>
It's UNIX/Linux specific.
______________________________________
In standard C, we can make use of fseek() & ftell().
And, don't forget fgetpos() & fsetpos().

The manual says:
On some non-UNIX systems an fpos_t object may be
a complex object and these routines may be the only
way to portably reposition a text stream.

[Walter Roberson]

In article <3m*************@individual.net>,
Alexei A. Frounze <al*****@chat.ru> wrote:

<mu*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googleg roups.com...

so, is there any way to find the sizeof file in standard C

long fsize (const char* name)
{
long pos;
FILE* f=fopen(name,"rb");
if (!f) return -1;
if (!fseek(f,0,SEEK_END))
pos = ftell(f);
else
pos = -1;
fclose (f);
return pos;
} That would be the most portable implementation.

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

An offset of 0 in combination with SEEK_END is defined for text
streams, but the result of the ftell() not portably be the file size
in bytes -- the result of ftell() for text files is permitted to
be an opaque data structure.
--
Any sufficiently old bug becomes a feature.

[junky_fellow]

Walter Roberson wrote:

In article <3m*************@individual.net>,
Alexei A. Frounze <al*****@chat.ru> wrote:

<mu*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googleg roups.com...

so, is there any way to find the sizeof file in standard C

long fsize (const char* name)
{
long pos;
FILE* f=fopen(name,"rb");
if (!f) return -1;
if (!fseek(f,0,SEEK_END))
pos = ftell(f);
else
pos = -1;
fclose (f);
return pos;
}

That would be the most portable implementation.

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

An offset of 0 in combination with SEEK_END is defined for text
streams, but the result of the ftell() not portably be the file size
in bytes -- the result of ftell() for text files is permitted to
be an opaque data structure.

You are right.
N869 Page 271:
"Setting the file position indicator to end-of-file, as with fseek
(file, 0, SEEK_END), has undefined behavior for a binary stream
(because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the
initial shift state. "

[Chris Dollin]

Alexei A. Frounze wrote:

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

mu*******@gmail.com wrote:

...

Tell us why you want to know the file size.

Tell us what's wrong with such a desire? How about malloc'ing memory for
the entire file? How about comparing files (1st check being file size
check)? How about checking if there's enough space on some media to store
it before trying to store at all?

I wasn't asking you for your speculation; I was asking the OP for
their objective. What answer we give would depend on the objective.

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Chris Dollin]

mu*******@gmail.com wrote:

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

*Why* do you want to know the size of the file?

[Note that "the size of a file" need not be an unambiguous term.]

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[emanshu, Munish Nayyar]

Hi Chris,

I am developing one real time protocol.
and my requirement is my rate control calaculation algorithm requires
file size.

also, the protocol i am developing is to use UDP and Provide QoS and
reliability and Real Time characterstics in proposed protocol.

I hope this is more than enough information.

now can u help me.

rgrds,
Munish Nayyar
emanshu "Innovative MInd"
Zazu Networks,Inc.
mn*****@zazunetworks.com

[Richard Bos]

ju**********@yahoo.co.in wrote:

Walter Roberson wrote:

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

I'm not entirely sure.
You are right.
N869 Page 271:
"Setting the file position indicator to end-of-file, as with fseek
(file, 0, SEEK_END), has undefined behavior for a binary stream
(because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the
initial shift state. "

That's a non-normative footnote, though. The actual text says:

# A binary stream need not meaningfully support fseek calls with a
# whence value of SEEK_END.

Note: meaningfully. IMO, the logical interpretation is that a binary
stream must support SEEK_END, in that fseek() is not allowed to crash
(and thus it's not truly undefined behaviour), but that the value
returned need not have any connection to reality.

Richard

[Chris Dollin]

emanshu, Munish Nayyar wrote:

Hi Chris,

I am developing one real time protocol.
and my requirement is my rate control calaculation algorithm requires
file size.
So, if it's real-time code, anything that reads through the file
in advance isn't acceptable, yes?

On the other hand, a reasonable *approximation* to the file size
would be OK, yes?

This code isn't intended to be ANSI-portable, because the real-time
features won't port cleanly, yes?
also, the protocol i am developing is to use UDP and Provide QoS and
reliability and Real Time characterstics in proposed protocol.

I hope this is more than enough information.

I'd say that given your requirements, use whatever non-portable system
calls for file size your platform supports: a clean ANSI-C solution
is neither available nor desirable.

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Richard Bos]

"David Lee" <li*******@gmail.com> wrote:

[ Learn to use Google, or get a real newsreader. Quote context! ]

#include <sys/types.h>
#include <sys/stat.h>
It's UNIX/Linux specific.
Quite; and therefore off-topic here.
In standard C, we can make use of fseek() & ftell().
But not reliably to find the size of a file, which is what the subject
line tells me you are after.
The manual says:
_Which_ manual?
On some non-UNIX systems an fpos_t object may be
a complex object and these routines may be the only
way to portably reposition a text stream.

Quite. Not a reliable way to get a file size, then.

Richard

[ahmed.mubin]

go through stat/lstat/fstat function

[Robert Gamble]

ah*********@gmail.com wrote:

go through stat/lstat/fstat function

Huh? I have no idea what you are talking about since you quoted
absolutely no context. Whatever you were trying to reply to though,
your response is off-topic here.

Robert Gamble

[emanshu, Munish Nayyar]

Chris Dollin wrote:

emanshu, Munish Nayyar wrote:

Hi Chris,

I am developing one real time protocol.
and my requirement is my rate control calaculation algorithm requires
file size.
So, if it's real-time code, anything that reads through the file
in advance isn't acceptable, yes?

But calculation of size of file and then calculating the rate control
both are not an real time issue.

real time here is file transfer. but i my problem is before that.


On the other hand, a reasonable *approximation* to the file size
would be OK, yes?

This code isn't intended to be ANSI-portable, because the real-time
features won't port cleanly, yes?

also, the protocol i am developing is to use UDP and Provide QoS and
reliability and Real Time characterstics in proposed protocol.

I hope this is more than enough information.
I'd say that given your requirements, use whatever non-portable system
calls for file size your platform supports: a clean ANSI-C solution
is neither available nor desirable.

this solution might be acceptable, but for that i need to know about
the System calls for different OS.
i am just looking for alternative solution

rgrds,
Munish Nayyar
--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Alexei A. Frounze]

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

Alexei A. Frounze wrote:

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

mu*******@gmail.com wrote:

...

Tell us why you want to know the file size.

Tell us what's wrong with such a desire? How about malloc'ing memory for
the entire file? How about comparing files (1st check being file size
check)? How about checking if there's enough space on some media to store it before trying to store at all?

I wasn't asking you for your speculation; I was asking the OP for
their objective. What answer we give would depend on the objective.

I treated what you wrote as if it was written as "there's no reason to know
the file size at all". Just that.

Alex

[Alexei A. Frounze]

<ju**********@yahoo.co.in> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Walter Roberson wrote:

....

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

An offset of 0 in combination with SEEK_END is defined for text
streams, but the result of the ftell() not portably be the file size
in bytes -- the result of ftell() for text files is permitted to
be an opaque data structure.

You are right.
N869 Page 271:
"Setting the file position indicator to end-of-file, as with fseek
(file, 0, SEEK_END), has undefined behavior for a binary stream
(because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the
initial shift state. "

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Alex

[Walter Roberson]

In article <3m*************@individual.net>,
Alexei A. Frounze <al*****@chat.ru> wrote:

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Linux has support for a fair number of different filesystem types.
Did you try them all? How big is the index on that DVD? What happens
when you NFS over to an OpenVMS system? What size does your code
report /dev/zero to be?
--
This signature intentionally left... Oh, darn!

[Keith Thompson]

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

Alexei A. Frounze wrote:

> "Chris Dollin" <ke**@hpl.hp.com> wrote in message
> news:dd**********@malatesta.hpl.hp.com...
>> mu*******@gmail.com wrote:
> ...
>> Tell us why you want to know the file size.
>
> Tell us what's wrong with such a desire? How about malloc'ing
> memory for the entire file? How about comparing files (1st check
> being file size check)? How about checking if there's enough
> space on some media to store it before trying to store at all?

I wasn't asking you for your speculation; I was asking the OP for
their objective. What answer we give would depend on the objective.

I treated what you wrote as if it was written as "there's no reason to know
the file size at all". Just that.

Then you misunderstood. When he wrote "Tell us why you want to know
the file size", he probably meant "Tell us why you want to know the
file size.".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"Alexei A. Frounze" <al*****@chat.ru> writes:
[...]

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Almost all the people I've met speak English. This doesn't lead me to
assume that everyone does. (Noting your ".ru" address and fluent
English, this is not aimed at you, it's just an example of an invalid
inference.)

When you view them from the perspective of all operating systems,
Windows and Linux are really very similar to each other. Certain
mainframe operating systems can do some very odd things.

I suspect that on all systems where feek() and ftell() give you the
correct size, there's a system-specific method to get the size of a
file directly. It's probably safer to use the system-specific
method(s), using #ifdefs to cover as many systems as you know about,
than to use the indirect and not quite portable fseek()/ftell()
method. If your program uses the stat() function and looks at the
st_size member of the result, you can be sure it will fail to compile
if you try to port it to a system that doesn't support stat(). If you
use feek() and ftell(), it may just quietly give you incorrect results
(as well as being less efficient on systems where it works).

Not all code has to be portable, and there is such a a thing as good
non-portable code vs. bad non-portable code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Dollin]

Alexei A. Frounze wrote:

"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:dd**********@malatesta.hpl.hp.com...

Alexei A. Frounze wrote:

> "Chris Dollin" <ke**@hpl.hp.com> wrote in message
> news:dd**********@malatesta.hpl.hp.com...
>> mu*******@gmail.com wrote:
> ...
>> Tell us why you want to know the file size.
>
> Tell us what's wrong with such a desire? How about malloc'ing memory
> for the entire file? How about comparing files (1st check being file
> size check)? How about checking if there's enough space on some media
> to store > it before trying to store at all?

I wasn't asking you for your speculation; I was asking the OP for
their objective. What answer we give would depend on the objective.

I treated what you wrote as if it was written as "there's no reason to
know the file size at all". Just that.

You read more into my request than I wrote into it, in that case,
as well as crediting me with precious little in the way of imagination.

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Simon Biber]

Lew Pitcher wrote:

I can only think of two methods to determine file size that are consistant with
the C standard:

1) fopen() the file,
initialize an unsigned long (or longer) variable to 0
until fgetc() returns end of file, add 1 to the counter
fclose() the file,

Hmm, let's see how that looks in C:

file = fopen(the file);
do {
unsigned long variable = 0;
} until (fgetc(file) == EOF);
counter++;
fclose(file);

Doesn't look very promising. Perhaps you missed some punctuation after
the zero?

--
Simon.

[Lew Pitcher]

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

Simon Biber wrote:

Lew Pitcher wrote:

I can only think of two methods to determine file size that are
consistant with
the C standard:

1) fopen() the file,
initialize an unsigned long (or longer) variable to 0
until fgetc() returns end of file, add 1 to the counter
fclose() the file,

#include <stdio.h>
{
FILE *fp;
unsigned long count;

if ((fp = fopen("the file","r")) != NULL) /* fopen() the file */
{
count = 0; /* initialize count to 0 */
while (fgetc(fp) != EOF) ++count; /* until fgetc returns EOF, */
/* add 1 to the counter */
fclose(fp); /* fclose() the file */
}
}


Hmm, let's see how that looks in C:

file = fopen(the file);
do {
unsigned long variable = 0;
} until (fgetc(file) == EOF);
counter++;
fclose(file);

Doesn't look very promising. Perhaps you missed some punctuation after
the zero?

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDATBHagVFX4UWr64RAiMbAJwIvzeLCG9TIzhbfLXnHz MMe2cOUgCeOxo6
lk0pGN1IBXNA0S35eIcLGp8=
=d4q5
-----END PGP SIGNATURE-----

[Walter Roberson]

In article <Bd*******************@news20.bellglobal.com>,
Lew Pitcher <lp******@sympatico.ca> wrote:

#include <stdio.h> {
Hmmm, no main() .
FILE *fp;
unsigned long count;
Is a file size certain to fit within an unsigned long?
Answer: NO.

For example, SGI IRIX programs compiled in either
32 bit mode have 32 bit unsigned long, but the SGI XFS filesystem
supports individual files up to about 10 terabytes.
if ((fp = fopen("the file","r")) != NULL) /* fopen() the file */
And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.
{
count = 0; /* initialize count to 0 */
while (fgetc(fp) != EOF) ++count; /* until fgetc returns EOF, */
/* add 1 to the counter */
If I recall correctly, on systems that differentiate between
binary and text streams, opening with "r" opens as a text stream.
The number of chars read from a text file could be more or
less than the binary file size. On the other hand, Similarily,
if the file was written as text and is being read as binary, the
"size" isn't going to match either.

Now that I think of it, I don't recall that the standard promises
that a file written as text has any consistant meaning when read
as binary. For example, some systems automatically compress older
text files, and transparently uncompress them when the file is
read back as text -- but because the compressed file must be
manipuable in compressed format, reading the file in binary might
give you the compressed form. In such a system, reading a text file
in binary might give you different answers at different times.

The C standard doesn't care: it's promises are framed in terms
of what is read back in text mode after being written in text mode,
and in terms of what is read back in binary mode after being
written in binary mode.

fclose(fp); /* fclose() the file */
}
What value does count have here if the file was unreadable?
}

Since count was local to this block, the value of count has
disappeared by here, but you have not returned any value
nor assigned into any result variable that has a lnnger
lifetime. The optimizer thus might decide to throw away
the 'count' variable. Indeed, the only thing stopping the
compiler from optimizing away *everything* is the fact
that "the file" might be a named pipe and so there might
be side effects from having done the read (that and the
fact that in Unix the act of doing the read changes the
"last accessed" time.
--
Look out, there are llamas!

[Richard Bos]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

In article <Bd*******************@news20.bellglobal.com>,
Lew Pitcher <lp******@sympatico.ca> wrote:

#include <stdio.h>

{

Hmmm, no main() .

FILE *fp;
unsigned long count;

Is a file size certain to fit within an unsigned long?
Answer: NO.

No, but it's the largest size integer you can get under C89.

if ((fp = fopen("the file","r")) != NULL) /* fopen() the file */

And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.

If it isn't, what do you want the file size for in the first place?

Richard

[Walter Roberson]

In article <43****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.

If it isn't, what do you want the file size for in the first place?

Back when 18 Gb was a big disk, I used to have batch jobs that
scanned looking for old big files. I didn't need to look inside
the files, only to find out how big (and how old) they were;
the top abusers would then be sent email asking them to please
clean up.
--
Look out, there are llamas!

[Richard Bos]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

In article <43****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.

If it isn't, what do you want the file size for in the first place?

Back when 18 Gb was a big disk,

And when you tell youngsters these days that, they won't believe you?
Must be all of what, five years ago?
I used to have batch jobs that
scanned looking for old big files. I didn't need to look inside
the files, only to find out how big (and how old) they were;
the top abusers would then be sent email asking them to please
clean up.

In that case, you specifically do _not_ want to know the file size as C
sees it, but the amount of space it takes on the disk - including slack,
et cetera. And if that's what you want, there really is no C answer,
since that number depends not only on OS, but even on the file system,
and possibly on the size of the disk itself.

BTW, that would've been a prime candidate for a shell script rather than
a C program. Even, I think, under M$ OSes.

Richard