Thread: what am I doing wrong with this fseek?

The second argument of fseek() is a long int, not an unsigned long long. ftell() also returns a long, not a long long. Supplying constants of longer type (0ull as the second argument of fseek()) or making the variable size have type unsigned long long, does not magically change change the values that fseek() handles or that ftell() returns.

If the file size happens to exceed what can be stored in a signed long, there is no magic that extracts the actual size. You will need to use functions that are specific to your operating system if you want to work with large files.


Also, leaving the return type off main() is generally considered poor form, these days. Even by fans of K&R.

> long ftell(FILE *stream);
Your file is larger than a long.

Use fgetpos() instead, as it should be able to deal with any size your file system supports.

However, I notice the use of \\, which means you're not using Unix/Linux, which means surprises are likely.

What OS and Compiler are you using?

Originally Posted by Salem

Use fgetpos() instead, as it should be able to deal with any size your file system supports.

Well .... the OP's example is seeking to print the file size. fgetpos() does not retrieve a position in a file in a form that can be interpreted as a value (except by fsetpos()) or printed.

> I am using Code::Blocks GCC under Windows 7 64bit
Code::blocks (via MinGW) uses the Microsoft runtime library, which means you have all the bugs and incompatibilities thereof.

Size Specification
Now it seems about a decade late, but MS finally seems to support ll as a format.
However, given your older library issue, it seems you would have to use "I64" to print a long long.

> printf ("size is : %ull", size);
Since you got 0ll printed, it seems your version ignored the ll suffix, just used the %u to print 0, then printed ll as just any other character which is not part of a format.

> the OP's example is seeking to print the file size. fgetpos() does not retrieve a position in a file in a form that can be interpreted as a value (except by fsetpos()) or printed.
Yes - portable 64-bit file access is indeed a problem.

> I am hoping to write code that can be compiled for Windows, Mac OSX, and Linux so I want to avoid wherever possible OS specific code
You mean like g:\\ isn't specific enough already?

When writing portable code, you should look to create your own wrapper functions around the variable functionality.
Eg.

Code:

#ifdef WIN32
// Windows
long long myGetFileSize ( const char *filename ) {
    long long result = -1;
    LARGE_INTEGER answer;
    HANDLE hFile = CreateFile( filename, ... );
    if ( GetFileSizeEx(hFile,&answer) ) {
        result = (long long)answer;
    }
    CloseHandle(hFile);
    return result;
}
#else
// assume POSIX
long long myGetFileSize ( const char *filename ) {
    long long result = -1;
    int fd = open(filename,O_RDONLY);
    if ( fd >= 0 ) {
        result = lseek64(fd, 0, SEEK_END);
    }
    close(fd);
    return result;
}
#endif

In a larger project, you'll end up with several of these, so it make sense to have
- porting.h containing all the prototypes
- porting_win32.c containing all the win32 stuff
- porting_posix.c containing all the posix stuff

So you compile all your code, and whichever of the porting.... files makes sense for the platform you're using.

Forgive my ignorance please. Where do I find good information to accomplish these tasks you have set before me? I am researching on google and not comming up with too much information. where do I find the right implementation and syntax for Win 32 ,I've been up all night trying to absorb and understand these concepts. Google returns pages that has the prototypes but no examples. I know that it is possible I mean even 32bit processors and 32 bit OSs can handle 256bit encryption. I am not worried about the porting at this point I just want to get it to work in windows 7 64bit even though I am using GNU GCC which I understand to be a 32bit compiler. I am reading from several books and no where is the mention of stuff like O_RDONLY or fgetpos(), I am really struggling with this in part that I am a newbie and the other reason is that these seem esoteric because I cannot find them in the books that I have and I have a lot. The prototypes for these confuse me.
I thank you guys for trying to help me and being so patient with me. Please don't give up on me.
I tried visual C++ 2011 for my compiler(nor do I wish for it to be my compiler as it runs on interpreted code) and I did not understand it at all it had a bunch of extra stuff in it that I did not understand and my code wouldn't compile like it did when I was using GNU GCC. I know that you guys are trying to make me understand but I guess I should sleep and let it sink in maybe that will do it.
I am not looking for someone to do the work for me, I simply want to understand all of this.
Thank you.

I suggest you learn as much standard C as possible on a single platform before worrying about the intricacies of getting portable code to work across a range of platforms.

I am trying Pelles C 64bit with this code:

Code:

#include <stdio.h>
int main()
{


unsigned long long size;
FILE *f = fopen("g:\\Mess.m2ts", "rb");
if (f)
   fseek(f, 0ull, SEEK_END);
   size = ftell(f);
   fclose(f);
   printf ("size is : %ull", size);

return 0;
}

and it returns the value 4150372352LL
this is better but still wrong
What am I doing wrong?
if I change it to lld in all the places I get -144594944
if I change it to unsigned int I get 4150372352

What are you doing wrong?

The first obvious thing is that you have not addressed your original problem (apart from giving main() an explicit int return type, that code is identical to the code in your first post) but you are hoping that using a different compiler will fix it.

Nothing to do with it. A 64-bit compiler is able to address more memory. Support of long long integral types is something else entirely.

And it doesn't change the fact that you are using functions that the standard specifies as working with long types, rather than long long types.