Thread: Reading and Writing file chunks

Hi, I need some help with reading in 1 mb of binary data, and writing it to a different file. I want to continue this until the whole file has been read and written to the new one. I've searched around and I have found nothing useful. Thank you for taking the time to look.

Code:

#include <stdio.h>

int main(int argc, char *argv[])
{
      FILE *fp;
      FILE *out;

      size_t = result;

      int size = 1024 * 1024; // 1 mb
      int i;

      char *buffer;

      out = fopen("file.bin", "wb");

      for(i = 0; i < argc; i++)
      {
            fp = fopen(argv[i + 1], "rb");
            
            while(!feof(fp))
            {
                result = fread(buffer, size, 1, fp);
                if(result != size)  Error("Could not load into memory\n");
                
                if( fwrite(buffer, 1, size, out) != size)  Error("Error writing file to bin\n");
                
                free(buffer);
             }
             fclose(fp);
       }

       getchar();
       return 0;
}

size_t= result;

Should be...

size_t result;

Buffer is never actually defined (It doesn't point to anything)

free(buffer); // Doesn't do what you think it does...

Code:

if(result != size)  Error("Could not load into memory\n");

This test will break your program if your file is not an exact multiple of "size", since the last fread will read less than "size".

So, I shouldn't have a 1 mb char, but a 4 kb one? Won't that take forever then?

What if the entire file has been read, with the last buffer being a full one. Won't it loop again, and then read nothing?

Great! It's working nicely.

Is there a problem though if a funtion parameter is an int, but you supply a size_t? They are both integral so won't it be ok?

size_t might be long long though, depending on the file system allowing greater than 4 GB files. That's why the library functions use 'size_t' so that it's flexible independent of size of long (32 bits) or long long (64 bits). And who knows how large int is - it's usually some nice machine-friendly size depending on whether the hardware and/or compiler is fundamentally 32 bit or 64 bit.

So to answer your question - if you are passing 'int' you may not have enough size, or too much size, relative to the file system. You end up casting, but you may truncate bits.

So if possible (which it is) I should change to a size_t?

If you are writing a wrapper function for the file I/O library functions, then yes. That way the user is forced, outside of calling your function, to understand the correct integer size that's expected. Any casting and maybe truncation he encounters will be his doing. It won't be your problem. You have done all you can to make your wrapper function “future proof” if Microsoft decides to change the definition of size_t again. In other words, your wrapper function is always in sync with the library function.