I've been working on resize.c for a day or two and I don't think I understand the code of copy.c well enough to solve the problem. I am very confused about how bf and bi just turn into pointers. In the struct they're declared as BITFILEHEADER and BITINFOHEADER the same goes for triple. Why is there a & in front of bi, bf, and triple whenever a read, write etc. function is called? Please help.

P.S i've included the copy.c code in case it is helpful for constructing an answer:)


* copy.c * * Computer Science 50 * Problem Set 4 * * Copies a BMP piece by piece, just because. */



include "bmp.h"

int main(int argc, char* argv[]) {

// ensure proper usage
if (argc != 4)

    printf("Usage: ./copy compression infile outfile\n");

    return 1;

// remember filenames
int compression = atoi(argv[1]);
char* infile = argv[2];
char* outfile = argv[3];

if(compression < 0 || compression > 100)
    printf("Usage: resize needs to be between 0 and 100\n");
    return 2;

// open input file 
FILE* inptr = fopen(infile, "r");
if (inptr == NULL)
    printf("Could not open %s.\n", infile);
    return 3;

// open output file
FILE* outptr = fopen(outfile, "w");
if (outptr == NULL)
    fprintf(stderr, "Could not create %s.\n", outfile);
    return 4;

// read infile's BITMAPFILEHEADER
fread(&bf, sizeof(BITMAPFILEHEADER), 1, inptr);
printf("%p\n", &bf);

// read infile's BITMAPINFOHEADER
fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);


// ensure infile is (likely) a 24-bit uncompressed BMP 4.0
if (bf.bfType != 0x4d42 || bf.bfOffBits != 54 || bi.biSize != 40 || 
    bi.biBitCount != 24 || bi.biCompression != 0)
    fprintf(stderr, "Unsupported file format.\n");
    return 5;

// write outfile's BITMAPFILEHEADER
fwrite(&bf, sizeof(BITMAPFILEHEADER), 1, outptr);

// write outfile's BITMAPINFOHEADER
fwrite(&bi, sizeof(BITMAPINFOHEADER), 1, outptr);

// determine padding for scanlines
int padding =  (4 - (bi.biWidth * sizeof(RGBTRIPLE)) % 4) % 4;

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
    // iterate over pixels in scanline
    for (int j = 0; j < bi.biWidth; j++)
        // temporary storage
        RGBTRIPLE triple;

        // read RGB triple from infile
        fread(&triple, sizeof(triple), 1, inptr);

        // write RGB triple to outfile
        for(int e = 0; i < compression; e++)
            fwrite(&triple, sizeof(triple), 1, outptr);


    // skip over padding, if any
    fseek(inptr, padding, SEEK_CUR);

    // then add it back (to demonstrate how)
    for (int k = 0; k < padding; k++)
        fputc(0x00, outptr);

// close infile

// close outfile

// that's all folks
return 0;


1 Answer 1


It seems you're having trouble understanding the concept of memory addresses.
All variables are stored in memory, their addresses is the position in memory where the contiguous "space" or "slot" they are currently occupying begins.
& gets the address of the variable, in other words, the memory addresses of bi, bf and triple is being passed to fread which reads from a pointer to a file and writes to the address being passed in the first argument, and fwrite which reads from the address being passed in the first argument and writes to the file pointer.
If you're not sure what a function does you can write man function in the terminal, for example:
man fread
Then you can read informations about the function.

  • Thanks so much! yeah I went back and went over fread() and I understand it now. Thanks also for the man function I did not know that. I added some things to my code I don't know what I'm doing wrong could you help me please?
    – blueless
    Aug 31, 2016 at 1:54
  • I would suggest to start again from another copy of copy.c, as you're not sure what you're doing it may cause too many problems to alter the code provided, instead you can try to only write code relative to the output, meaning you should avoid altering code related to the input or opening of files. I would suggest to try to only alter bi and bf, as these get written to the ouput, and the loop which is responsible for resizing the image.
    – thomas
    Aug 31, 2016 at 3:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .