Copying Files

Check the above, it is for copying files.

So my question is : Using an int for copying, is it safe for every file e.x. mp3's pdf's etc. Or is there another way such as byte (bit) copy just for safety ?

Code:

#include <stdio.h> 
#include <stdlib.h> 

static FILE *open_file ( char *file, char *mode )
{
  FILE *fp = fopen ( file, mode );

  if ( fp == NULL ) {
    perror ( "Unable to open file" );
    exit ( EXIT_FAILURE );
  }

  return fp;
}

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

  if ( argc != 3 ) {
    fprintf ( stderr, "Usage: %s <readfile1> <writefile2>\n", argv[0] );
    exit ( EXIT_FAILURE );
  }

  in = open_file ( argv[1], "r" );
  out = open_file ( argv[2], "w" );

  while ( ( ch = fgetc ( in ) ) != EOF )
    fputc ( ch, out );

  fclose ( in );
  fclose ( out );

  return EXIT_SUCCESS;
}

Originally Posted by ch4

So my question is : Using an int for copying, is it safe for every file e.x. mp3's pdf's etc. Or is there another way such as byte (bit) copy just for safety ?

If you are using fgetc, you need to use an int as the return value. However, if you want to copy a "binary" (such as an mp3, etc), you would want to use fread into a signed char buffer. This is because a signed char is literally one byte, and a file is literally a series of bytes, which are signed char values (-128 to 127). Although this is a number, it is not at all a C integer, which is 4 bytes (or 8 bytes on 64bit) long.

There may be a problem with how fgetc reacts to 0, which can exist in a binary file but does not occur in text files.

Originally Posted by MK27

If you are using fgetc, you need to use an int as the return value. However, if you want to copy a "binary" (such as an mp3, etc), you would want to use fread into a signed char buffer. This is because a signed char is literally one byte, and a file is literally a series of bytes, which are signed char values (-128 to 127). Although this is a number, it is not at all a C integer, which is 4 bytes (or 8 bytes on 64bit) long.

There may be a problem with how fgetc reacts to 0, which can exist in a binary file but does not occur in text files.

more standard way will be to use unsigned char buffer with fread and represent bunary data as hex 0x00-0xFF

fgetc has no problem with 0x00 char. Why do you have any doubt in it?

you need int to store the return value of fgetc because data read from file use range from 0 to 255 and EOF condition is signaled with the negative value EOF (on most compilers -1)

Originally Posted by vart

more standard way will be to use unsigned char buffer with fread and represent bunary data as hex 0x00-0xFF

fgetc has no problem with 0x00 char. Why do you have any doubt in it?

Fair enough. I don't use fgetc, so that's why I wrote may. I suppose there is no difference between a signed and unsigned char in this context as long as you do not mix them up.

you need int to store the return value of fgetc because data read from file use range from 0 to 255 and EOF condition is signaled with the negative value EOF (on most compilers -1)

That would definitely be a problem then, since a binary file will contain a -1 sooner or latter. Use fread -- or just use file pointers and read(), which I think is how fread is actually implimented.

Originally Posted by MK27

That would definitely be a problem then, since a binary file will contain a -1 sooner or latter.

Ah, but as the 1999 edition of the C Standard puts it, "the fgetc function obtains that character as an unsigned char converted to an int".

Originally Posted by laserlight

Ah, but as the 1999 edition of the C Standard puts it, "the fgetc function obtains that character as an unsigned char converted to an int".

So fgetc should be fine, is what you're saying. I kind of thought that was the case, since an EOF is not actually a -1. However, it will be awkward if you want to get the whole file into memory before you copy it out -- or for that matter retain anything more than a single byte.

Originally Posted by MK27

an EOF is not actually a -1.

As vart pointed out, EOF is typically -1, and in any case it must be a negative int constant.

Originally Posted by MK27

However, it will be awkward if you want to get the whole file into memory before you copy it out -- or for that matter retain anything more than a single byte.

Awkward? Not likely, since you can just copy into an array. On the other hand, one might as well read in blocks.

Originally Posted by laserlight

As vart pointed out, EOF is typically -1, and in any case it must be a negative int constant.

If you use a signed char, you will find lots of -1 in (eg) a .jpg image. And if you use an unsigned char, there is no such thing as -1. I do not think the EOF is even one real byte, in fact.

Originally Posted by MK27

If you use a signed char, you will find lots of -1 in (eg) a .jpg image. And if you use an unsigned char, there is no such thing as -1.

fgetc() does not return a signed char or an unsigned char, but an int.

Originally Posted by MK27

I do not think the EOF is even one real byte, in fact.

It is not. EOF is a value used to denote "end of file", or some error. This is why vart is so certain that "data read from file use range from 0 to 255", and that there will not be conflicts between actual data read by fgetc() and EOF (though vart does assume that the range of unsigned char is [0,255], but that is a reasonable assumption).