"When I run my implementation of resize.c in check50, there are two "TODO's" in red at the bottom of some sections. Does anyone know what this means? (My programs output is identical to the staff's implementation, verified with diff)"

-asked Aug 27 at 20:22 by Mike Stache

I have the same issue with check50.

I tested for padding discrepancies with "xxd -c 28 -g 3 -s 54" for a resize of 3. I compared the result with CS50's resize.c code output (for resize of 3) and there was no visible difference.

Is there another reason, other than padding, that could cause two "TODO's?"


The other reason is if the header values are wrong; generally it's bfSize and biSizeImage that seem to be the culprits.

Did you compare the headers when you resize by 3?

  • no I didn't, and they do differ...bytes 3, 4, 35 and 36.
    – Sal
    Nov 30 '14 at 22:44
  • sorry, i think I meant (with reference of first byte as byte 0) 2,3, 34, and 35 bfsize and bisizeimage was incorrectly modified and copied.
    – Sal
    Nov 30 '14 at 22:58
  • So you're all set now?
    – curiouskiwi
    Nov 30 '14 at 23:07
  • It looks as though the check50 does not update the bi.biSizeImage nor the bf.bfSize values (please confirm?). I thought we were required to update said values, is that not the case?
    – Sal
    Nov 30 '14 at 23:34
  • Yes, you need to update the values. Check50 will give you all green smiles if your values are correct.
    – curiouskiwi
    Nov 30 '14 at 23:35

You must log in to answer this question.

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