Timeline for Why does copy.c skip padding?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2019 at 16:22 | history | edited | Cliff B | CC BY-SA 4.0 |
added 5 characters in body
|
| Jan 20, 2016 at 12:15 | comment | added | Vitale | 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? | |
| Jan 20, 2016 at 11:22 | comment | added | Vitale | @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 ) | |
| Jul 29, 2015 at 4:39 | comment | added | SwiftSilent | Okay that makes sense. Thanks for the help! :D | |
| Jul 29, 2015 at 3:07 | comment | added | Cliff B | 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. | |
| Jul 29, 2015 at 2:57 | comment | added | SwiftSilent | 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? | |
| Jul 29, 2015 at 2:55 | vote | accept | SwiftSilent | ||
| Jul 29, 2015 at 2:51 | history | answered | Cliff B | CC BY-SA 3.0 |