CSC 209 lab 10 exercises, week of 19 July 2022

Where to find solutions:

Attendance

Remember that you can check that your attendance has been recorded properly at https://wwwcgi.teach.cs.toronto.edu/~ajr/cgi-bin/auth/present

Part 1: C-preprocessor abuse

b) Contrary to the parenthetical advice above, perhaps try writing something like this yourself.

Part 2: Critiquing and improving C code

Some of it does work, but is unnecessarily complicated or otherwise unnecessarily difficult to read. Your task for this lab is to simplify such code, maintaining its function.

Some of it works only in straightforward conditions but performs incorrectly in boundary cases or error conditions.

Example question 1:

Code excerpt:

void g()
{
    int d = x + 5;
    if (d < e) {
        [ten lines of code not involving 'd']
    }
    [twenty lines of code not involving 'd']
}

Solution:
Change "if (d < e)" to "if (x + 5 < e)" and get rid of the 'd' variable. This is simpler, but more importantly, with the original code the reader will be looking for where 'd' is used later on. And suppose, for example, that in future we need instead to compare "if (x + 6 < e)". Should we change d to "x+6" or will this cause trouble elsewhere? Unless this d value is very meaningful, the simpler version, without the additional variable, is much clearer for these sorts of reasons.

Question 2:

Code:

int f(int x)
{
    int d = x + 3;
    return(d);
}

[solution] (the problem is repeated on the solution page, for each of today's problems)

Question 3:

Code:

    if (stat(file, &statbuf)) {
        printf("%s: No such file or directory\n", file);
        exit(1);
    }
    fp = fopen(file, "r");

[solution]

Question 4:

Code:

    if ((fp = fopen(file, "r")) == NULL) {
        perror("opening the file");
        exit(1);
    }

[solution]

Question 5:

Code:

int fexists(char *file)
{
    struct stat *p;
    p = malloc(sizeof(struct stat));
    return(stat(file, p) == 0 && S_ISREG(p->st_mode));
}

[solution]

Question 6:

    long t;
    ...
    if (stat(filename, &statbuf)) {
        perror(filename);
        exit(1);
    }
    t = (long)statbuf.st_mtime;
    ...

[solution]

Question 7:

Code:

int foonumber()
{
    int x;
    FILE *fp = fopen("foo", "r");
    if (fp == NULL)
        perror("foo");
    if (fscanf(fp, "%d", &x) == 0)
        return(-1);
    return(x);
}

[solution] (there are at least three entirely separate problems with this code)

Question 8:

Code:

int main(int argc, char **argv)
{
    if (argv[2] == NULL) {
        printf("two integers required on the command line");
        return(55);
    }
    printf("%d", atoi(argv[1]) + atoi(argv[2]));
}

[solution] — but don't look at the solution after you've fixed just one problem -- there are at least five!

To submit:

Code:

#include <stdio.h>

int main(int argc, char **argv)
{
    FILE *fp;
    char c;

    if (argc < 2)
	printf("put a file name");

    fp = fopen(argv[1], "r+");
    while ((c = getc(fp)) > 0)
	putchar(c);
    fclose(fp);

    return(1);
}

You can find the above text in /u/csc209h/summer/pub/lab/10/lab10.c
Submit your improved program in a file named "lab10.c".

Your should not add or change anything which is not specifically to fix a defect in the above program. However, your program should behave like a proper unix program — for example, one of the defects above is the incorrect exit status. Its error handling and error message(s) are also wrong.

Programs which do not compile with "gcc −Wall" with no errors or warnings will not get the mark for this lab. However, this is not the only cleanup required. I count ten defects above (although it does depend on how you count), of which you must fix at least six (without introducing any new defects nor changing anything irrelevant) to get the mark.

Submit your file with

        submit -c csc209h -a lab10 lab10.c

Q: What does "r+" do in the fopen()?
A: It opens for read-write — after that, it is possible either to read from or to write to the file. Thus this fails if the file is read-only.