Timeline for pset4 recover, 000.jpg correct, but middle and last incorrect
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 25, 2016 at 7:36 | vote | accept | user13479 | ||
| Aug 25, 2016 at 7:16 | comment | added | Cliff B | 1. As written, yes. But when you change it from 4 to 512 bytes, it's going to hold the last 508. If not explicitly allocated, it's going to hit a seg fault for trying to store data well past the undefined length body[]. The random sig isn't in your data file, but it is in the one used by chek50. They're sneaky like that. ;-) 2. you were lucky. sometimes it works, sometimes not. It depends on what is stored in physical memory immediately after. More often than not, that will cause a problem with check50 because that's a far more active system where memory is extensively used and reused. | |
| Aug 25, 2016 at 7:10 | comment | added | user13479 | 1. BYTE* body[] in the struct didn't specify any size, so it's just there, not doing anything? So the code processed 4 bytes. BUT my code wasn't caught by any random signatures. The code still recovered all the 50 images. Was it just a coincidence? 2. I only allocated 7 bytes for the file names, but it didn't seem to cause any problems. Why was it? 3. Yes, I figured out that just a simple array can do. | |
| Aug 25, 2016 at 7:04 | comment | added | user13479 | Your answer is very helpful. But I still have some questions. | |
| Aug 25, 2016 at 5:11 | history | answered | Cliff B | CC BY-SA 3.0 |