fputc fgetc file incomplete reed

Code:

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

/*  bmp file copy test fputc fgetc */

int main(){
    
    int a ;
    int b ;
    char ch ;
    char buffer;
   FILE *ptrout ;   
    FILE *fp;
    
    if ((fp = fopen("example2.bmp", "r+b")) ==NULL){
  printf("Error opening file\n");
  exit(1); 
          }
          
 
 
     if ((ptrout = fopen("ee2.bmp", "w+b")) ==NULL){
  printf("Error opening file\n");
  exit(1); 
          }  
                    
          


a = 0 ;   
      while ((ch = fgetc(fp)) !=EOF) {
          /*  buffer = ch ; */
          
            /* fputc( buffer , ptrout); */
            
            fputc( ch , ptrout);            
            a = a + 1 ;
            }
            
            printf(" Filesize[a] = %d \n\n", a );
            
            
 
   fclose(fp);                           
   fclose(ptrout);
 /*  fclose(fp); moved infront of ptrout */
   printf("Done....");
  
  system("PAUSE");    
  
  return 0;
}

seems to copy the header fine but where is the rest of the file? ee2.bmp is 54 bytes but the orignal file is 12,400 bytes. It should be a straight copy. meow. Tried using both rb and r+b. moved fclose to see if placement made any difference. Devcpp console .c code compiles no errors.

Even when I replace EOF with SEEK_END it will read more or the next block but not the entire file. I have a win32 prog that will read and display a bmp file so I know the win32 works but not the console. It seems the console prog is has a problem reading the file. I do not know why. Any thoughts?

try

Code:

    int ch ;

instead of

Code:

    char ch ;

to read more
Kurt

Ok changed char ch to int ch. Also had feof and only 4 bytes rw. Then changed feof back to EOF. And then it worked. Still do not know why using different feof and endseek did not work.


works now. Meow.

Code:

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

/*  bmp file copy test fputc fgetc */

int main(){
    
    int a ;
    int b ;
    int ch ;
    char buffer;
   FILE *ptrout ;   
    FILE *fp;
    
    if ((fp = fopen("example2.bmp", "r+b")) ==NULL){
  printf("Error opening file\n");
  exit(1); 
          }
          
 
 
     if ((ptrout = fopen("ee2.bmp", "w+b")) ==NULL){
  printf("Error opening file\n");
  exit(1); 
          }  
                    
          


a = 0 ;   
      while ((ch = fgetc(fp)) != EOF ) {
          /*  buffer = ch ; */
          
            /* fputc( buffer , ptrout); */
            
            fputc( ch , ptrout);            
            a = a + 1 ;
            }
            
            printf(" Filesize[a] = %d \n\n", a );
            
            
 
   fclose(fp);                           
   fclose(ptrout);
 /*  fclose(fp); moved infront of ptrout */
   printf("Done....");
  
  system("PAUSE");    
  
  return 0;
}

EOF is usually represented as -1.
if you read a white pixel ( char 255 ) it is converted to -1 -> eof
There is a reason why fgetc returns an in.
Kurt

>Even when I replace EOF with SEEK_END it will read more or the next block but not the entire file
Well u cant use SEEK_END in your application. It is basically used for fseek function. The SEEK_END is a macro to replce 2. But the EOF is a mcaro to represent the a End of File and which it macros to a negative value.

ssharish

feof() just checks the stream flag. That means it tells you if a previous read encountered EOF. Because of this, you can check feof(), and it'll return false because no previous reads resulted in EOF, and then the next char you read will be EOF.... That means if you misuse feof() as a control loop (like the FAQ says not to), you can end up acting upon EOF chars.

Code:

try
Code:

    int ch ;

instead of
Code:

    char ch ;

to read more

That does not make sense. An 8 bit int is the same as and 8 bit char. Yeowwww! <extreme brain pain>

Code:

That means if you misuse feof() as a control loop (like the FAQ says not to), you can end up acting upon EOF chars.

read the faq again. Ok I understand the problem with it.

Originally Posted by kryptkat

That does not make sense. An 8 bit int is the same as and 8 bit char. Yeowwww! <extreme brain pain>

What kind of system are you using where an int is 8 bits?

The whole point is that int is bigger than 8 bits, so it can represent ALL of the unsigned char values 0-255 as well as -1 meaning EOF. On a system where int and char were both 8 bits things would be "interesting" indeed, as you would be unable to distinguish between a character value of 255 and EOF.