pset6 server trapped in if (connected())

Question

I am so frustrated by pset6, so much unfamiliar stuff here...... please help!

I have written all the 4 to-do functions, however if I go to the web server, no matter what I clicked, it shows no more than < ?.

It seems a lot goes wrong.

So I go to gdb, setting the breakpoint at main, and find out the server.c falls into the line if(connected()) and does not show anything anymore.

I am confused because by if(connected()), it has not yet touched any of the 4 functions I wrote, there shouldn't be anything wrong....supposedly?

I really need advice, thanks!

Here is load:

/**
 * Loads a file into memory dynamically allocated on heap.
 * Stores address thereof in *content and length thereof in *length.
 */
bool load(FILE* file, BYTE** content, size_t* length)
{
    // bsic settings
    int counter = 0;
    BYTE* buffer = malloc(1);

    while(fread(buffer, 1, 1, file) == 1)
    {
        counter = counter + 1;
    }

    buffer = realloc(buffer, counter + 1);
    fread(buffer, 1, counter, file);
    *(buffer+counter) = '\0';

    *content = buffer;
    *length = counter + 1;

    if (content == NULL || length == NULL)
    {
        return false;
    }

    return true;

}

Answer 1

New load

• The first advice is: do not think of content or treat content as "string" (char*) data. It will sink you. Because a byte containing 0 has special meaning (ie null terminator), the system will be fooled. Image data can (and usually does!) contain lots of 0 bytes. Consider a black pixel (review pset4 spec for a refresher).
• Similarly, this declaration char* buffer = malloc(2); (and everything that goes with it: memset, free) is adding unnecessary complexity. Since the function reads file one BYTE at a time, and the program has given us a handy-dandy data type called BYTE, think about how the function could be simplified using a declaration like this BYTE buffer;.

• Back to "string" thinking: this * length = strlen(* content) + 1; is a problem. Your program just went to all that trouble to read the bytes from file and build counter. You already have the exact info you need. And be mindful of the places you use counter + 1. That is also "string" thinking.

• load must return a length that matches the file size exactly. When you are using gdb, you might want to know what length to expect. One way to find the size/length of a file is the ls -al command. If you are in your public directory, ls -al will give output similar to this, file lengths highlighted:

  

• Remember, when you make a request to your server, as with CS50 IDE > Web Server, the first thing it requests is the "document root", followed by favicon.ico. It might be easier to send a curl request like curl -i http://localhost:8080/hello.html when you are troubleshooting with gdb.

• Frustration is the enemy. This pset is quite challenging, to be sure. Trust what you know, research/review what you don't, and use the tools (debug50, gdb, valgrind).

---

Original analysis This sizeof(BYTES) might not be the only problem, but it is significant. BYTES is an integer. sizeof an integer is 4. I don't think that's what you intended. It's used in two places in the load function.

And make sure you review the spec

given a /path/to/a/directory, returns /path/to/a/directory/index.php if index.php actually exists therein, or /path/to/a/directory/index.html if index.html

Order matters. (This is not related to the errors you are facing, but it will be a factor with check50/server2).

When you use gdb, it is usually a good idea to set breakpoints at the functions you wrote, instead of main.