Thread: Problem with a for() loop.

  1. #16
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    Quote Originally Posted by stahta01 View Post
    Do you open the file in Binary Mode?
    This is not needed under Linux; but, required under Windows.

    Tim S.
    You have two files involved are they both opened in Binary?

    Tim S.

  2. #17
    Member
    Join Date
    Mar 2011
    Posts
    40
    EVOEx: You're not understanding at all. Of course the files aren't the same on both Linux and Windows. I've already stated that the Windows data is BROKEN and that I'm trying to find a way to fix it. After so many replies into the topic, I realized that Quzah was saying that the 0A Bytes are read as 0D 0A because of how Windows handles text. What I was saying is that the same source code was the only data that was the same. Also, the pseudo-code was given just to better illustrate the problem after people got confused when I posted the true data. It appears I just need a fix for the 0A to 0D 0A problem.

    stahta01: Files are being opened in binary mode, yes. As can be seen in these code snippets:
    Code:
        portfrom=fopen(portfromentry,"r+b");
        portto=fopen(porttoentry,"r+b");
        displaylist=fopen("temp1.zmuffin","w+b");
        vertexdata=fopen("temp2.zmuffin","w+b");
        texturedata=fopen("temp3.zmuffin","w+b");
    Last edited by Flotonic; 06-06-2011 at 06:17 PM.

  3. #18
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    They are opened now that way, but were they opened then that way?

    Now = when you have the current data you are trying to magically fix.
    Then = when the files were actually created.

    Also, how did you get them from one machine to another? Did you ftp them over in text mode, or binary mode? Did you create it from scratch over again on the other computer?

    What matters now is how you plan on fixing it (and what you do with it in the future). Why don't you just re-copy the data back over correctly from your *nix machine?


    Quzah.
    Hope is the first step on the road to disappointment.

  4. #19
    Member
    Join Date
    Mar 2011
    Posts
    40
    Previously, they were worked with in a Hex Editor, so they were most likely in Binary Mode at that time, too. The data that the program is reading is straight from video game files, of course.

    Even though I've been using a Windows compiler under Wine, I have had an actual Windows user compile it and get the same issue. The video game files are being downloaded via a website.

    My current plan for fixing it is to...
    > Call eight more byte variables.
    > When data is grabbed, write them to a temporary file.
    > Go back eight bytes and grab the bytes written to the temporary file. Compare to the original eight bytes and delete the one that is different.

    That is my concept of a workaround for the 0A to 0D 0A problem. However, when writing the contents of the temporary file to the video game file itself, this can't be done because deleting a byte would offset the rest of the data in the file.

    Is there a way to simply write the contents of one file to another without having to take risks with a loop that grabs a byte from the temporary file and writes it to the final file until complete? The way Windows parses bytes keeps me from doing this part.

  5. #20
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    "The way Windows parses bytes keeps me from doing this part."

    It's not so much how Windows parses bytes, as how you are telling Windows to parse bytes. If you get a "clean" copy of your data, and never touch it except in binary mode (which your hex editor may or may not do, and it wouldn't completely surprise me if it didn't, and something like Notepad would certainly not do), then you won't have a problem.

  6. #21
    Member
    Join Date
    Mar 2011
    Posts
    40
    I'm re-downloading the files and doing this with perfectly clean data each time. Besides, when a file is opened in binary mode, Windows should be told to treat it as binary. Ohh well.

  7. #22
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Quote Originally Posted by Flotonic View Post
    I'm re-downloading the files and doing this with perfectly clean data each time.
    If this were true, we wouldn't be having this discussion. Have you checked a downloaded-but-otherwise-unmessed-with Windows file with a downloaded-but-otherwise-unmessed-with *nix file with file sizes (and maybe checksums)? (I'm assuming that all your files, even if differing from person to person or run to run, are all the same size. If you can use just one file on both systems, that would be superb.)

    Once you make sure you have a clean copy, then open with "rb" and no transformations will happen.

  8. #23
    Member
    Join Date
    Mar 2011
    Posts
    40
    I just had a Windows user try opening the file and copying it to and empty, fresh, new one. They still get the errors, even though the copy is 100% clean and not modified from what is found in the game.

  9. #24
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by Flotonic View Post
    I just had a Windows user try
    So it's not actually you who is testing your code.
    Quote Originally Posted by Flotonic View Post
    opening the file and copying it to and empty, fresh, new one.
    What does that even mean?
    Quote Originally Posted by Flotonic View Post
    They still get the errors, even though the copy is 100% clean and not modified from what is found in the game.
    What does that even mean? What error? Doing what?
    Code:
    #include<stdio.h>
    int main( void )
    {
        FILE *fp1, *fp2;
    
        fp1 = fopen( "mywindowsfile", "rb" );
        fp2 = fopen( "myunixfile", "rb" );
    
        if( fp1 && fp2 )
        {
            int c1, c2;
    
            while( (c1 = fgetc( fp1 )) == (c2 = fgetc( fp2 )) && c1 != EOF )
                ;
    
            printf( "Your files are %sdifferent.\n", c1 == c2 ? "not " : "" );
    
            fclose( fp1 );
            fclose( fp2 );            
        }
        return 0;
    }
    Quzah.
    Hope is the first step on the road to disappointment.

  10. #25
    Member
    Join Date
    Mar 2011
    Posts
    40
    I'm testing my code. It works flawlessly for me. For people on Windows, though, after so many bytes are read, the data starts getting screwy and eventually just becomes FF FF FF FF Bytes (NULL). I'm sensing there is a trick behind it, like how you need to use fflush(stdin); each time you use a getchar(); statement. Something similar may be needed here. I actually tested creating a file full of seemingly random bytes for the Windows user to test. When they ran the program, even though there were a few 0A Bytes in the first twenty or so bytes, they didn't transform into 0D 0A, so it has to be something related to a statement that needs used with the fgetc(); statements.

    I made a program similar to your file compare program yesterday as well and had a Windows user test it. It only got one byte from each file at a time and it seemed to work for them. I can't modify the program to get just one byte at a time, though, because it checks them in an eight-byte-aligned mode, so I need to get eight at a time.

    Also, opening the file and copying it would be opening the file in a hex editor, copying its data to an empty file, and saving as a new file. Having a clean, never opened file is a solution made by tabstop, who I thank for their support, but it didn't really change the output for Windows people.

    Sorry if my words are confusing.

  11. #26
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Quote Originally Posted by Flotonic View Post
    like how you need to use fflush(stdin); each time you use a getchar(); statement.
    Actually, you should never use fflush(stdin). It's undefined behavior. fflush is only defined for output streams. Read about it here: Cprogramming.com FAQ > Why fflush(stdin) is wrong, and about some alternate solutions here: Cprogramming.com FAQ > Flush the input buffer.

  12. #27
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    What type is byte1 to byte8?
    You need to check for end of file on input; why it works on Linux is unknown.

    FF is likely the end of file indicator.

    Tim S.

  13. #28
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Go download this utility for Windows: WinMD5 Free - Windows MD5 Utility Freeware.

    Get the md5sum of your "100% clean and not modified from what is found in the game" Windows file. Then on *nix, type the following at the command line: "md5sum /path/to/game/file". Make sure both files are fresh downloads. Paste the results of both into a new post on this thread for us to see. Dollars to doughnuts, your Windows and *nix files are different before you even open them.

  14. #29
    Member
    Join Date
    Mar 2011
    Posts
    40
    Anduril462: Wow, thanks! I didn't know about that. I haven't used fflush(stdin); since I made simpler programs on Windows, but that is very useful to know.

    Stahta01: I have them all stored in integer (int) form, even though I could use unsigned char, seeing how FF is the maximum for a byte, which is also the maximum of an unsigned char.

    Anduril462:
    The results follow.
    Linux: 0431300f23001a4f19819a712db2608c
    Windows: 0431300f23001a4f19819a712db2608c

    Image Verification:
    Linux.
    Windows.
    Last edited by Flotonic; 06-07-2011 at 12:27 PM.

  15. #30
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    So can you post your latest code to try and read that file?
    If you're using "rb" for your fopen() calls, it should be working the same.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with loop.
    By Squish in forum C++ Programming
    Replies: 2
    Last Post: 10-12-2010, 09:21 AM
  2. loop problem
    By sababa.sababa in forum C Programming
    Replies: 6
    Last Post: 12-20-2009, 02:56 PM
  3. For Loop problem
    By lawzbhoy in forum C++ Programming
    Replies: 4
    Last Post: 05-14-2008, 11:39 AM
  4. for loop problem
    By Makoy in forum C++ Programming
    Replies: 1
    Last Post: 12-25-2004, 10:08 AM
  5. While loop problem
    By nadkingcole in forum C Programming
    Replies: 2
    Last Post: 05-09-2002, 06:14 AM