0

recover.c seems to be working just fine. But then I realized I didn't employ a condition which tests the end of file. Why does it still work then? Should I modify my while condition?

In addition to that I don't really get why recover.c fails the check50 test if I don't initialize the pointer img to NULL.

Here's the code. (Pseudocode starts with the while loop).

int main(int argc, char* argv[])
{
    uint8_t buffer[512];
    char title[8];
    FILE *img = NULL; //FILE *img; -> this won't let me pass the check50 test
    int count = 0; 
    FILE *card = fopen("card.raw", "r");

    if (card == NULL)
    {
        printf("Could not open %s.\n", "card.raw");
        return 1; 
    }

    while(fread block of size buffer)
    {
        if (jpeg headers are found)
        {
            check if img is open otherwise close it
            sprintf the img
            open a new img
            fwrite onto img
        }
        else if img is open
        {
            fwrite onto img
        }
    }

    fclose(card);
    return 0;
}
2
  • you program has mismatched paranthesis.
    – Wafeeq
    Jun 22, 2016 at 16:37
  • Thank you Gullu, I'm going through your suggested edits now
    – Alberto
    Jun 22, 2016 at 21:36

1 Answer 1

1

I've seen that a couple of times lately. Here's what I believe is happening. When you create a pointer without initializing it, it will contain whatever random garbage data happens to be in the memory location of the variable (not to be confused with what it points at.) Note that NULL is represented by binary 0. In a newly started computer's memory, or one that has had it's memory cleared, it's possible that it may contain the equivalent of null when you run locally, because much of the memory still contains binary 0's. However, when run on the very active check50 servers, memory is more likely to contain random, non-zero data. When it hits that pointer in your code, it tries to access invalid memory, probably seg faults, and thus check50 fails it.

At least, that's my theory. ;-)

As for why it ran on your system without the check, I don't know. To even guess, I'd have to see actual code, particularly the while loop setup. But if I had to guess, I'd say that you had the read in the while loop. Remember that the while condition does return a value which would be evaluated to true or false. If it returned 0 at any time, that would be evaluated as false. But without seeing code, anything is a guess here.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

3
  • Thank you Cliff for the answer. I'm ok now with pointers but still befuddled as to why it works without a check on the end of file. Here's my while loop: pastebin.com/Ud9Q9JXQ
    – Alberto
    Jun 22, 2016 at 8:52
  • It's exactly what I thought. When you put the fread in the while loop, it actually does the EOF check via the return value. fread() returns the number of elements successfully read. When EOF is encountered, the number returned is 0, which is interpreted by the while loop as false, terminating the loop. This is, in fact, the correct way to do that.
    – Cliff B
    Jun 22, 2016 at 18:46
  • Thank you Cliff. Now it's all clear to me.
    – Alberto
    Jun 22, 2016 at 21:37

You must log in to answer this question.

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