I'm having a bit of a hard time understanding certain lines of code in copy.c. For example below:

// 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);

If padding is so important since each scanline of a BMP file has to be a multiple of 4 bytes, why is copy.c skipping over padding? Then why and how is it able to add it back to the bitmap?

Also, what does this look like visually? Is padding always placed at the end of each scanline?


In the demo code that merely copies a bitmap, they are demonstrating how to strip off the padding and then add it back when writing to the outfile because that ability will be needed later.

Yes, every scan line has padding at the end because each line needs to end on a 4-byte boundary. Keep that in mind because when you are scaling the image up to a larger size, the amount of padding needed will change unless the scaling factor is 1 or a multiple of 4.

So, when you read in the date from the source file, you get the relevant data, the pixels, and then skip over or discard the padding. Then, when you scale up, you write out the pixels x scaling factor, and then add the appropriate amount of padding for the output file, which you must calculate for the output file scan line length. Finally, note that you can't just multiply the input padding by the scaling factor to get the output padding.

If this answers your question, please accept this answer to remove the question from the unanswered question pool. Let's keep up on forum housekeeping. ;-)

  • This cleared things up for me a lot. So does: fseek(inptr, padding, SEEK_CUR); put the cursor at the before or after of the padding? – SwiftSilent Jul 29 '15 at 2:57
  • It depends on where SEEK_CUR is pointing. If SEEK_CUR is pointing at the first char of padding, then yes. Simply put, it says to move the position pointer for file inptr. Start at SEEK_CUR and change by the value of padding. So, hypothetically, if SEEK_CUR were pointing at byte 104, and padding = 3, then the pointer would point at position 107 after this was executed. – Cliff B Jul 29 '15 at 3:07
  • Okay that makes sense. Thanks for the help! :D – SwiftSilent Jul 29 '15 at 4:39
  • @Cliff B: May I still bring this up, or is the question closed? I will give it a shot in hope to get help. I don't understand why code comments say "skip over padding", if in fact it looks as if it adds padding after all colored pixels have been written to the outfile. As you say, if SEEK_CUR were pointing at byte 104, then after fseek cursor points at 107, and than the program adds additional padding bytes by calling for loop and fputs. I am stuck ) – Vitale Jan 20 '16 at 11:22
  • I got it! I think I understand how it works: fseek "moves" cursor within infile to the end of scanline, and therefore with the next round of the outer for loop fread starts reading the inptr from that position; this is why fread reads new scanlines with each iteration of the for loop. Correct? – Vitale Jan 20 '16 at 12:15

This is a late answer but is relevant as I feel that the actual question was not answered. I had the same question and while searching for answer reached this post."why is copy.c skipping over padding? Then why and how is it able to add it back to the bitmap?"

fseek has been already explained. The inptr (from fopen) is skipping the padding (inptr after reading each scanline then skips over the padding). The outptr is adding padding after writing the scanline. I think the question is asking why the padding being added afer skipping padding but misses the point that it is different pointers that are skipping padding vs adding padding.

You must log in to answer this question.

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