Notes on Assignment 1: A Chat Program

These are some general notes on assignment 1.

Grading

A generally correct assignment received a B. If I felt that the overall design of your program was somewhat awkward, I gave you a B-. If I felt that there were particularly nice aspects of your program, I gave you a higher grade.

Some Notes on the Original Code

You may recall that there were a pair of lines in the original code on the order of

fgets(buf, sizeof(buf), stdin);
buf[MAX_LINE-1] = '\0';

Why do we put the 0 character at the end of the string? If there was no carriage return in the first MAX_LINE characters, there is no 0 character to terminate the string. While this won't cause a problem for send, it will cause a problem on the other side when it goes to print. Now, I'm not sure why we get sizeof(buf) characters rather than sizeof(buf)-1, but that's a problem for another day.

Common Problems

A number of you wrote something like the following

int spew(int s, char *buf, int len)
{
  while (fgets(buf, MAX_LINE, stdin)) {
    ...
  } /* while we get lines. */
} /* spew */

• Why make buf and len parameters rather than local variables.
• You need to document what this returns.
• You need to make this return something if the loop exits (even though it's not supposed to exit).

Sam's C Preferences

• I find if (!strcmp(a,b)) an awkward way to write ``if a and b are the same''. I prefer if(strcmp(a,b) == 0), since it is marginally clearer.
• I prefer to see the documentation for your functions by the function declarations (in the header file or at the top of the file) rather than by the function definitions.
• If you have more than two or three functions in your file, you should organize them (preferably alphabetically once you've grouped them in sections). It may also be helpful to have a table of contents at the top, particularly if your file goes on for more than two or three pages.
• Please don't leave debugging messages in your final code. If you really think they'll be useful later, try a strategy that lets you turn them on or off. See the handout on debugging messages for help.
• The best way to "comment out" code is with #ifdef. For example,

  #ifdef EXPERIMENTAL
    /* These lines are unlikely to work.  I've left them here to remind
     * myself never to try it again.
     */
    yadda();
    yadda();
    yadda();
  #endif
  

  That way, you can reincorporate those lines by changing your compile flags.
• Only use break to exit loops when there is no other alternative. It's much harder to trace code that exits loops in the middle.
• Please don't put function definitions in your header files.
• For some reason, Netscape has not been cooperative about saving the right files under the right file names. It helps me if you put the name of the file at the top of the file.

Sample Solutions

For the first solution, I put everything into one file. The way in which you run the executable determines whether it acts as a client or a server. You can find that solution as chat.c in the course examples.

For the second solution, I used separate files. chatserver.c is the server. chatclient.c is the client. chatutils.c contains the functions used by both server and client. chat.h defines shared functions and common constants.

Finally, the Makefile describes how to build everything.