Printable View
I once made a script in C to receive a file name as argument in *argv and using fopen i would read each char until EOF. At the same time i would be calculating its size using sums.
I cant remeber how much i would sum for each char i read, but that method was very ineficient and slow.
Are there better examples of how to do it?
ftell() is a standard function that will tell you the position from the beginning of a file. The fseek() function has an option to set the fileposition relative to the end of the file, so combining those two will tell you how long the file is without reading any of the content.
--
Mats
Another (not portable) solution: if you're on a *nix machine, the stat() function
call can get some low-level information about the the file, including its size in bytes.
If the file is a symbolic link st_size gives the length in bytes of the path name contained in the sym. linkCode:#include<stdio.h>
#include<sys/stat.h>
int main(int argc, char **argv){
struct stat stbuf;
if(stat(argv[1], &stbuf)==0)
printf("-I- File size in bytes: %ld\n", stbuf.st_size);
return 0;
}
I think there's an equivalent function call in MSWin, but since this is not a
standard C function YMMV, depending upon what you're using
hope it helps
There's also a stat() function on Windows.Quote:
Originally Posted by gradstudent
I would think that passing the file pointer to a strlen like function would be pretty efficient and fast if you are tallying up all the pointers to char. Double check sizeof(char) for your system though.
sizeof(char) is always one.
1) that wouldn't work.Quote:
Originally Posted by slingerland3g
2) sizeof(char) is always 1. Always.
That would give you a warning in C and if you ignore it, most likely a crash to undefined behavior. In C++, it would never compile.Quote:
Originally Posted by slingerland3g
Late response:
Hmm not sure where you all were going with what I said. But tallying up all the chars within a file or string will give you it's size in bytes. The below should work, so maybe my wording of what I was trying to explain was off a bit.
Code::
/*continue to read in file*/
while (*filePointer++)
{
length++;
}
return length;
:
:
This works for a string and indeed, what most strlen implementations do, but it won't work for a file whose type is FILE*.
Besides, it's also a very inefficient method for finding the size of a file.
"type is FILE*." Ok, ok.
Thanks
FILE is a struct. How do you propose to use that as a boolean expression?
That's impossible in C, so what you propose won't compile.
Not to mention FILE is not an array, so trying to walk it using ++ would be undefined behavior.
It would work on char*, char[], but not FILE*.
Actually, I wouldn't want to guarantee that FILE is NOT an array - in many systems it would be. The problem with using ++ on a file-pointer, however, is that the struct FILE is not a known type in the application side, it's only known in the C-library side of the code (it's called an opaque pointer - it's a pointer to a struct, but you never "look inside it").Quote:
Originally Posted by Elysia
Being an opaque pointer means that there's no way to use ++ on it, since the compiler is not able to figure out how much forward it should jump.
And of course, even if we could "walk" the list of FILE structs, the code would definitely not tell you how big the file is - it would return some random value that is completely and utterly unrelated to the size of the file itself.
--
Mats
That's the closest thing I know of to a portable solution except that..... it doesn't work portably. With some operating systems or disk drivers, the call of fseek() can fail without returning any error code, after which the return from ftell() is unpredictable.Quote:
Originally Posted by matsp
This method also relies on an assumption that a file size cannot exceed the maximum value that is representable in a long int, which is not true with some recent compilers or target platforms.
I can't think of a reasonable solution to that one. Although I predict that this would also not work reliably for other fseek-related operations, so wouldn't that filesystem/disk driver be "black-flagged"?Quote:
Originally Posted by grumpy
In this case, the solution is to use the fgetpos/fsetpos functions, that take a "fpos_t" type - this type should be correctly sized for any file-size that the OS supports if the C library implementation is done correctly. Unfortunately, fgetpos/fsetpos are not standard functions, but exist in both Linux and MS runtime libraries at the very least.Quote:
This method also relies on an assumption that a file size cannot exceed the maximum value that is representable in a long int, which is not true with some recent compilers or target platforms.
--
Mats
Microsoft also has integer-64 versions of the fseek/ftell functions.
You mean _teilli64() - that's not a version of ftell() - it's a version of the linux tell() function.Quote:
Originally Posted by Elysia
But I also realized that fsetpos is not analogous to fseek in that it takes an absolute file position, so there's no way to say "move to 0 bytes from the end of the file".
--
Mats
No, I mean _ftelli64 and _fseeki64.
Ah, yes, found those now - somehow, when I was looking at fsetpos, it didn't have _fseeki64. Googling for that specifically does however show it up.Quote:
Originally Posted by Elysia
--
Mats
Such systems still have a significant market share. The real world is like that sometimes: the technically best or even right is not necessarily what survives.Quote:
Originally Posted by matsp
Just out of curiosity, what systems are those? I just can't understand how you would be able to for example build a working database system with a seek function that "doesn't always work". Or are we talking only on certain types of media (say CD-ROM or tape)?Quote:
Originally Posted by grumpy
--
Mats