recover.c: expected exit code 0, not 2?

Question

Here is the my second post regarding the same pset problem: recover.c. Running checks.......

:) recover.c exists.
:) recover.c compiles.
:) handles lack of forensic image
:( recovers 000.jpg correctly
expected exit code 0, not 2
:( recovers middle images correctly
expected exit code 0, not 2
:( recovers 015.jpg correctly
expected exit code 0, not 2

I really don't understand the meaning? expected an exit code of 0, not 2. Could somebody help me out with this?

#include <stdio.h>
#include <stdlib.h> // malloc()
#include <stdint.h>


int main(int argc, char *argv[])
{

  // ensure proper usage
  if (argc != 2)
  {
        fprintf(stderr, "Usage: ./recover image\n");
        return 1;
  }

// open input file
char *infile = argv[1];
FILE *inptr = fopen(infile, "r");
if (inptr != NULL)
{
    fprintf(stderr, "Could not open %s.\n", infile);
    return 2;
}

  typedef uint8_t BYTE;//unsigned integer data type
  BYTE buffer[512];
  int i = 0;// filename sequential number
  char* filename = NULL;
  int number = 0;//# of recovered images
  FILE *img;

  while(fread(buffer, 512, 1, inptr) ==1)
  {
     if(buffer[0] == 0xff && buffer[1] == 0xd8 && buffer[2] == 0xff && (buffer[3] & 0xf0) == 0xe0)
     {
           if(number >0)
           {
                 fclose(img);
           }
           sprintf(filename, "%03i.jpg", i);
           img = fopen(filename, "w");
           //fwrite(buffer, 512, 1, img);
           i++;
           number++;
     }
     else if(number > 0)
     {
          fwrite(buffer, 512, 1, img);
     }
  }

  fclose(inptr);
  fclose(img);
}

Answer 1

One of the skills that a programmer must develop is the ability to debug a program. In this light, I'll point you in the right direction.

When check50 reports an error of "expected exit code 0, not 2", it is reporting that the program terminated and returned a value of 2 to the operating system. Have you looked at the code to determine where this occurred? And having found that, have you determined precisely what caused the program to execute that block of code?

You need to be able to answer these questions and to investigate and resolve the root cause. Also, have you actually executed the program yourself to see what it is doing or are you just running check50? Just running check50 will not help you learn to debug your software, especially later when you're writing your own code and there is no check50 to test with. At that point, you'll have to create your own test cases and you'll have to have the skill to know how to design your own tests and the test data to support them. Just a piece of advice from a very seasoned software engineer.

Also, keep in mind that there are multiple issues that must be dealt with one by one. Don't get frustrated by this. First, multiple bugs in a first draft of a program is very common, especially at this stage in learning to program. Second, multiple bugs at this point are a good thing for you! It will give you a chance to learn to debug while the bugs are simple and usually independent of each other. As programs get more and more complex, bugs tend to interact and get hidden and harder to analyze, let alone fix. The experience will be a very good thing in learning programming.

If you're truly stumped after reanalyzing the code, come back and tell us what you've found and what you think. At that point, we'll give you some more direction so that you can find the answer, and more importantly, can develop your debugging skills.

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

Answer 2

I solved the problem by undoing changes in files that werent supposed to change. In example, in speller, you were suppossed to alter only dictionary.c. I my case it worked when I restored dictionary.h to the original file