Unexpected return value from fread()
Asked Answered
D

1

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

int main()
{
    FILE* bmp = NULL;
    uint32_t offset;
    uint8_t* temp = NULL;
    size_t read;
    unsigned int x_dim = 600, y_dim = 388;

    bmp = fopen("test_colour.bmp", "r");

    if (!bmp)
        return -1;

    /* Get the image data offset */
    fseek(bmp, 10, SEEK_SET);
    fgets((char*)&offset, 4, bmp);

    printf("Offset = %u\n", offset);

    temp = malloc(3*x_dim*y_dim*sizeof(uint8_t));

    if (!temp)
        return -1;

    /* Go the the position where the image data is stored */
    fseek(bmp, offset, SEEK_SET);

    /* Copy image data to array */
    printf("%u bytes requested!\n", 3*x_dim*y_dim);
    read = fread((void*)temp, sizeof(uint8_t), 3*x_dim*y_dim, bmp);
    printf("%Iu bytes read!\n", read);

    fclose(bmp);
    free(temp);

    return 0;
}

I'm using the above code to read the RGB data of a 24-bit per pixel BMP image to an array. The offset from the start of file where the image data starts (after the BMP header) is given at offset 10 according to the BMP specification. I get the following output when executing the above code.

Offset = 54
698400 bytes requested!
33018 bytes read!

The offset output seems to be correct because the file size is 698454 bytes (=698400+54). However, the value returned by fread() seems to indicate that not the entire image data could be read. However, I'm subsequently using the data in the temp array to convert the RGB data to greyscale and writing this data to a BMP file again. Visually checking the output image does not indicate any errors, i.e. it seems as if I actually read the entire input image in the first place although fread() seems to indicate differently.

Can someone explain this behaviour?

Dieball answered 30/7, 2012 at 7:34 Comment(7)
Two questions: 1) Can you check the contents of temp after the call to fread, to see if it actually stopped reading after 33018 bytes? 2) I am unfamiliar with %Iu format specifier - can you check the actual value of read in the debugger?Avignon
I don't think this is what's causing the symptoms you're seeing, but you should use the correct printf format strings. The format for size_t is "%zu". "%Iu" is non-standard. If your implementation doesn't support "%zu", you can use printf("%lu bytes read!\n", (unsigned long)read);Tetreault
I'm using gcc with MinGW to compile and the compiler does not recognize the %zu specifier (I tried using that one before). I read that one has to use %Iu in windows.Dieball
@simon: see https://mcmap.net/q/270679/-mingw-gcc-quot-unknown-conversion-type-character-39-h-39-quot-snprintf for some information on why MinGW can be a little confusing on the printf() format specifiers supported. Newer MinGW releases and/or newer versions of MSVCRT.DLL seem to support more and more of the C99 standard specifiers.Moton
"However, I'm subsequently using the data in the temp array to convert the RGB data to greyscale and writing this data to a BMP file again". can youu test the size of the new bmp file ? is it bigger than 33 KB ? is the dimention of the nem file is 600*388 pixels ?Gleeson
I tried to read an bmp file (600*388 pixels), the size I found is 698454 and i could read 698400 bytes (from Offset). you can try another file... copy it in another location.. (possible disk error).Gleeson
Yes and yes. It works fine when I use "rb". The only problem seems to be using "r" under Windows.Dieball
M
32

(I'll bet you're on Windows)

bmp = fopen("test_colour.bmp", "r");

should be

bmp = fopen("test_colour.bmp", "rb");

If the file is opened in text mode on Windows, the runtime will stop reading when it happens to hit a 0x1a (Ctrl-Z) byte, which Windows considers an EOF marker for text files. Even if it doesn't hit a Ctrl-Z, you'll get corrupted data when Windows converts CR/LF sequences into a single LF character.

However, I can't explain why you're able to get a good image from the partial file read (just lucky?).

You are able to render an image from the buffer because the fread() implementation does read the number of bytes you requested (or nearly so - the number gets rounded down to a multiple of some block size) into the buffer, then it scans the buffer looking for CR/LF sequences to convert and Ctrl-Z EOF flags.

So even though fread() returns 33018, the buffer has actually been nearly completely written with data from the file. The data isn't 100% correct (for example, some CR characters were probably discarded) or complete, but in this case it's close enough to render an image that looks like the one you expected.

Of course, this is simply an observation of how this particular runtime behaves currently - it may not always behave that way in the future (or even on all systems today).

Moton answered 30/7, 2012 at 7:53 Comment(4)
Indeed I am, forgot to mention in OP. Thanks for pointing that out, solved the problem! Are you sure it actually stops reading? As mentioned, I was still able to give out a correct greyscale image of the entire BMP image although according to fread only ~5% of the file data was actually read.Dieball
@simon: it's possible that the runtime reads the number of bytes you requested into the buffer, then goes through it and 'fixes-up' the line endings and EOF translations. But I'm just guessing.Moton
I compared the two output images generated (one by opening the file with "r" and the other one with "rb") with diff and they are not the same. Visually looking at the images, the only difference seems to be that the last few pixels in the "r" image are black while they should actually be white. So I guess fread actually reads more bytes than indicated by the return value, but not necessarily the actual number of bytes requested.Dieball
in '"r"' mode, some bytes are not read because of their values. so it is normal have less byte read in '"r"' mode than in '"rb"' mode. '"r"' mode is only for reading from a text file.Gleeson

© 2022 - 2024 — McMap. All rights reserved.