Lab01 Hints, CISC105, Fall 2004

This document contains:

  1. Some hints for getting the web ring working.
  2. A hint on debugging the lab01b.c program if you get either of the following error messages:

    invalid white space character in directive.

    warning: return type of `main' is not `int'

  3. General hints on lab01b.c if you are totally confused about what to do and where to start.

Note that you should first read over the update to lab01 for some corrections (the update document provides some corrections to errors/typos in the original assignment; this document offers hints to help you find the solutions, not corrections to the lab.)

1. Some hints about the web ring

  1. If you can't access your web pages after you create the files:

    ~/public_html/index.html
    ~/public_html/cisc105/index.html

    then try doing the following command:

    chmod -R a+rx ~/public_html

    See the following FAQ (frequently asked question) also: http://copland.udel.edu/~pconrad/UnixAtUD/105.181.FAQ.html#Q7
  2. Remember that you are actually creating two web pages for your lab01 assignment:

Make sure that after you add both of these web page, and after you do, do the "chmod" command listed above to make your pages accessible.

2. A hint for lab01b.c if you get a "invalid white space" error or the "return type of main is not int" error.

This hint is for students who basically understand what to do for the lab01b.c part of lab01, and just need help with the "illegal whitespace" error. If you are totally confused by this part of the lab, though, read item (3), "Extra help for lab01b.c" first.

If you have removed all of the other errors in the program, and you get either of the following, here are hints as to how to fix them. The fixes to these errors are not in your textbook.

> cc lab01b.c
"lab01b.c", line 6: warning: invalid white space character in directive
>
 

The fix to this error is to go into emacs, find the line of your program that says:

#include <stdio.h>^M

and get

rid of the ^M character at the end of the line. The ^M character sometimes shows up at the end of every line when files are transferred from DOS or Windows to Unix. Because this program came originally on the floppy disk that is bundled with your textbook, the ^M characters may be there (I later got rid of them in the file once I realized they were causing problems, but if you copied the file from my directory before I did this, you got stuck with the ^M characters.) Normally, these don't cause any problems, however, on the #include statement, with the cc compiler, apparently they do. The ^M characters is the "illegal white space" character that the cc compiler is complaining about; getting rid of it should make the message go away.

Next, if you see this message:

> gcc lab01b.c
lab01b.c: In function `main':
lab01b.c:8: warning: return type of `main' is not `int'
>
 

The way to get rid of this one is to change the line that says:

void main (void)

to say instead:

int main(void)

The gcc compiler simply expects the main program to return an int, rather than return a void. (I can explain more about this in lecture; if you are curious, ask.) The program will still work with void main(void), but the compiler issues a warning message, which is "messy". Using int main(void) instead cleans things up.

3. Extra help for lab01b.c

When you compile your lab01b.c program, it is normal to get many syntax errors. For example, here is the sequence of commands that you might initially type to get started on this part of the lab, and the errors that result:

> cd
> cd ~/cisc105/lab01
> ls
> cp ~pconrad/public_html/cisc105/04F/labs/lab01/lab01b.c .
> ls
lab01b.c
> cc lab01b.c
"lab01b.c", line 4: warning: old-style declaration or incorrect type for: Comments
"lab01b.c", line 4: syntax error before or at: are
"lab01b.c", line 4: warning: old-style declaration or incorrect type for: are
"lab01b.c", line 4: warning: old-style declaration or incorrect type for: valuable
"lab01b.c", line 4: warning: old-style declaration or incorrect type for: additions
"lab01b.c", line 4: warning: old-style declaration or incorrect type for: to
"lab01b.c", line 5: warning: old-style declaration or incorrect type for: programs
"lab01b.c", line 6: warning: invalid white space character in directive
"lab01b.c", line 6: cannot find include file: <stdioh>
"lab01b.c", line 7: only qualifiers allowed after *
"lab01b.c", line 8: syntax error before or at: debugging
"lab01b.c", line 8: newline in string literal
"lab01b.c", line 9: newline in string literal
"lab01b.c", line 10: invalid source character: '\'
"lab01b.c", line 10: invalid source character: '\'
"lab01b.c", line 10: invalid source character: '\'
"lab01b.c", line 10: newline in string literal
cc: acomp failed for lab01b.c
>

If you use gcc instead of cc, you get similar (though different error messages). Comparing the difference between cc and gcc error messages can be one way to help you figure out what is wrong.

> gcc lab01b.c
lab01b.c:6: stdioh: No such file or directory
lab01b.c:11: unterminated string or character constant
lab01b.c:8: possible real start of unterminated constant
>

It is your job to fix all of these errors by going into emacs, finding the mistakes, and fixing them one at a time. Some hints that may help:

  1. Each of the compiler messages has a line number associated with it, and an error message. Compare the compiler messages from gcc and from cc, and focus your attention on the first line that the compiler is complaining about.
  2. Look at your lab01b.c file, and compare that line, and the one right before it, with
    similar lines in some of the programs in the Tan and D'Orazio textbook (TD99) that ARE correct. What do you notice about the lines that the compiler complains about, when you compare them with similar lines in the " correct" programs?
  3. Reread Chapter 2 in the TD99 text (particularly helpful: Lesson 2.5, and Application Program 2.2, but you should really read the whole chapter.)

If you already did read it, look over it again, with the lines of your program that the compiler is complaining about "in mind". Trust me, if you do, you'll eventually figure out the problem and you'll know how to fix it.

You may find this process somewhat painstaking and detailed. If so, let me warn you now: this is what programming is often like. If it exceeds your pain threshold too much, you may want to think about whether this is the right course for you or not.

Note that when the last compiler message is gone, you are still NOT NECESSARILY FINISHED! You need to continue applying fixes to the program until the output (when you run ./a.out) matches exactly down to the last character and spacing, the sample output given in the textbook on page 73 (also repeated below). This may require some additional reading in Chapter 2. Watch especially where the line breaks and the periods are.

/// This is a program to help you practice "debugging".\\\
///There are a few errors in this program. You should be able
to fix them.\\\
Make your output neat and orderly.


Phillip T Conrad