Like Tree6Likes

what am I doing wrong with this fseek?

This is a discussion on what am I doing wrong with this fseek? within the C Programming forums, part of the General Programming Boards category; Code: #include <stdio.h> main() { unsigned long long size; FILE *f = fopen("g:\Mess.m2ts", "rb"); if (f) fseek(f, 0ull, SEEK_END); size ...

  1. #1
    Registered User
    Join Date
    Nov 2011
    Posts
    150

    what am I doing wrong with this fseek?

    Code:
    #include <stdio.h>
    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;
    }
    the filesize for Mess is 34,215,143,424 bytes but I am getting 011
    what is going on?

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    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.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    > 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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    I am using Code::Blocks GCC under Windows 7 64bit
    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 or at least make it where it can be changed with ease.
    Thanks for the replies and for the advise I will look for fgetpos() see if I can get a feel for the syntax of it.

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote Originally Posted by Salem View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    > 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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #7
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    the g:\\ can be changed easily to whatever OS syntax I need, I was speaking of hard to change stuff.
    What am I to do then? I need a way of telling how big a file is.
    Thanks

  8. #8
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    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.
    stahta01 likes this.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  9. #9
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    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.
    Last edited by Once-ler; 03-02-2013 at 09:26 AM.

  10. #10
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  11. #11
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    I have decided to learn it on windows first I will worry about porting later. I have tried various distros of Linux but that was before I got into programing. I chose C because before I tried C++ but it does not seem to have the low level abilities that I require plus it is hung up on that OOP stuff which I can't stand.

  12. #12
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    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
    Last edited by Once-ler; 03-02-2013 at 11:46 AM.

  13. #13
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    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.
    stahta01 likes this.
    Right 98% of the time, and don't care about the other 3%.

  14. #14
    Registered User
    Join Date
    Nov 2011
    Posts
    150
    well I would have thought that a 64bit compiler would have been able to work with ULL

  15. #15
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    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.
    Right 98% of the time, and don't care about the other 3%.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. What's wrong with my fseek() ?
    By barramundi9 in forum C Programming
    Replies: 5
    Last Post: 07-25-2011, 12:40 AM
  2. Reg. fseek
    By pokks in forum C Programming
    Replies: 1
    Last Post: 01-16-2006, 12:28 PM
  3. Help With fseek();
    By Explicit in forum C Programming
    Replies: 3
    Last Post: 05-26-2004, 08:40 PM
  4. fseek
    By Max in forum C Programming
    Replies: 5
    Last Post: 12-15-2003, 02:21 PM
  5. fseek ???
    By davie_scotland in forum C Programming
    Replies: 2
    Last Post: 02-19-2002, 05:13 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21