>I hear that this isn't always valid:
There are many, many, many different definitions of "file size",
(probably more than there are file sizes on a 64-bit machine) and
you need to decide which definition you want to use if you intend
calling any result "correct" or "incorrect" .
>FILE *in;
long size;
in = fopen("foo.bar" ,"rb");
fseek(in,0,SEE K_END);
size = ftell(in);
fseek(in,0,SEE K_SET);
then fread size many bytes into memory.
In binary mode, SEEK_END need not be meaningfully supported because
the system may pad the file with trailing 0 bytes. For example, CP/M
only counts sectors on binary files and rounds the size of the file
up to the next multiple of 128 bytes, and pads the last sector with
trailing 0 bytes.
In text mode, the size returned from ftell need not be meaningful as
a number. For example, it might be a bitfield of a number of values
like sector, head, cylinder, track, train, etc. so that subtracting
two of them does not give anything meaningful.
(Try, for example, subtracting 09302008 from 10022008, treating
them as decimal integers rather than dates, and try to make sense
out of the result that would indicate that they are 2 days apart.
The same kind of encoding can be done on text file offsets.)
Byte offsets into a text file are likely to be misleading because
of the \r\n -\n translation done by some systems (e.g. Windows).
>Apparently fseek is not guaranteed to work because of 0xFF EOF or other
characters,
There is no "EOF character". Even on one those systems which use
an end marker for text files (Windows), that marker isn't 0xFF.
Many systems (UNIX & variants) just store a file length (yet another
definition of "file size") and don't use an end marker.
EOF is a value that won't *fit* in a char (unless sizeof int ==
sizeof char) which is why getchar() returns int, not char.
>is this true only in text mode or also in binary mode?
You are screwed in both text mode and in binary mode for different
reasons.
>Is there
anyway to get a filesize
Do you want *A* filesize (in which case, I pick 0, it's easy, and
you didn't say it had to be correct, and some files actually do
have size 0) or do you want a *correct* filesize, in which case you
have to pick a definition of filesize?
>without having to read bytes on at a time. Is it
best to just fread until it fails?
If you want to read the file into memory, two definitions
of file size come to mind:
1. The number of bytes read from the file in binary mode.
2. The number of bytes read from the file in text mode.
Chances are high that these two definitions will give different
answers for the file size for any given file. Neither of these
necessarily says anything about how much space the file takes on
disk. But if you want to read the file into memory, these are
the right definitions to use (pick the one that uses the same
file mode as the file mode you're going to use).
