0

I'm currently writing a program that processes PPM files (P6 type, not P3) The problem is that some images have the byte 0x1b which, according to the ascii table is known as 'ESC'

The following is pretty much my code:

// all the includes there, , , ...

int main(void)
{
    FILE *finput;
    int number[7];
    char r, g, b;

    finput = fopen("my.ppm", "r");

    /*
       The code where I read the P6 numRows numColumns 255\n

       ...Lets assume that part works well 
    */


    while(!feof(finput))
    {
       num[0] = fscanf(finput, "%c", &r);    // the "num[] = " part is for debugging
       num[1] = fscanf(finput, "%c", &g);    
       num[2] = fscanf(finput, "%c", &b);


       printf("%d\n", num[0]);
       printf("%d\n", num[1]);
       printf("%d\n", num[2]);



    }
return 0; //or whatever...
}

For some reason, fscanf starts returning -1 after reading the 'ESC' byte (but the one that reads it does not return -1)

So the sample output would be:

1 -1 -1

On the other hand, I read the "while(!feof()) is always wrong" and the one about big files with fscanf, but my ppm images are not bigger than 500x500 pixels...

What can/should I do in order to be able to keep reading?

Thank you for your help!

user3596853
  • 23
  • 3
  • 1
    possible duplicate of ["while( !feof( file ) )" is always wrong](http://stackoverflow.com/questions/5431941/while-feof-file-is-always-wrong) – Barmar May 02 '14 at 17:19
  • 1
    Consider using `"rb"` instead of `"r"` for `fopen` (it makes a difference under Windows when you're dealing with binary files), and consider using `fgetc` if you're reading just one character. – zneak May 02 '14 at 17:20

1 Answers1

0

I'm guessing you're on Windows; a byte with value 0x1b means "end of file" for a text file on Windows. (See the comments; this explanation is wrong, but the solution worked, presumably because there is a 0x1a in the data).

You should open the file in binary mode:

fopen("my.ppm", "rb");

That will read all the bytes successfully. (It will also read both the \r and the \n of end-of-line markers.)

RichieHindle
  • 272,464
  • 47
  • 358
  • 399
  • 2
    0x1A (^Z) is EOF on Windows, not 0x1B – ikegami May 02 '14 at 17:38
  • @user3596853: Why did you accept my answer? Does it work for you? It seems like it shouldn't... – RichieHindle May 02 '14 at 18:08
  • Thank you very much kind stranger. Reading it in binary does make a difference. By the way, would there be any other differences between reading in binary and reading normally? like, would I have to use my fscanfs differently? or use something else all-together? Well, idk if it is because of that specific byte, but using "rb" did fix my problem. Thats why I accepted it. Although it is funny that to think that you would post a solution knowing/expecting it to fail – user3596853 May 02 '14 at 18:13
  • The solution might have helped even if the explanation was incorrect, but i don't see how. Or maybe the OP actually had 1A rather than 1B? – ikegami May 02 '14 at 18:20
  • 1
    Probably the byte *following* the `0x1b` is `0x1a` (text-mode `EOF` on Windows). The question states that the `fscanf()` call that "reads [the 0x1b character] does not return -1" - the subsequent `fscanf()` call does. – Michael Burr May 02 '14 at 18:30
  • And regardless of what's causing the `EOF` condition, see Barmar's comment about "'`while(!feof(file))`' is always wrong". – Michael Burr May 02 '14 at 18:32
  • @user3596853: In terms of reading a file sequentially as you are doing, the only differences between `"r"` (text) and `"rb"` (binary) on Windows is that in text mode a `0x1a` byte means End Of File, and `\r\n` pairs will be read as a single `\n`. – RichieHindle May 02 '14 at 18:40
  • @Michael Burr: In the details of my question, I did mention I had read that and it was of no use to me. @ikegami and @RichieHindle: There were all kinds of combinations since the ppm images contain anything from `0x00` to `0xff`. From the output, I could tell that `fscanf()` returned -1 after reading the `0x1b` though, but perhaps it was a `0x1a` that caused it. – user3596853 May 04 '14 at 05:14