Cpe 357 Laboratory Exercise 2

Due date TBA.




The Written Exercises (problems) are to be done individually.




The Laboratory Exercises are also to be done individually.




This looks kind of long, but none of the tasks below are terribly large.




Problems




These problems are designed to provoke some thought (could there be a quiz coming?):




(Warm up) Please provide declarations for the following data:



a pointer cp that points to a char.



a pointer ap that points to an array of chars.



a pointer pp that points to a pointer that points to an int.



Is it possible in C to declare and initialize a pointer that points to itself? Why or why not? (And, if so, how, of course.)



What is the fundamental problem with the following code fragment intended to print out a string:



char s[] = "Hello, world!\n"; char *p;




for(p = s; p != ’\0’; p++) putchar(*p);




What will happen when this is executed? How can it be fixed?




C programmers often say “arrays are the same as pointers”. In one sense this is true. In another, more correct, sense they are fundamentally different.



In what ways is this statement correct?



How is it in error? That is, what makes a pointer fundamentally different from an array?



Exercise 1.3 from Stevens APUE.



Exercise 1.4 from Stevens APUE, 3rd ed. (Ex. 1.5 in the 2nd.)



A subcase of Ex. 2.2 from Stevens: On unix5, what is the actual data type of a size t (the type of malloc(3)’s argument)? In what header file is it defined?



   





















































Figure 1: http://xkcd.com/371/




Laboratory Exercises




This hodgepodge of laboratory exercises designed to provide you with useful tools.




To help me with sorting out who’s who in the class (and three years from now when you write me out of the blue asking for a recommendation) I am asking you to submit a digital photo of yourself to the lab02 directory of the pn-cs357 account. I will not be sharing these with anybody so it doesn’t have to be glamorous, but it does need to be recognizable. That is, that great photo from last Halloween of you in your mummy costume really isn’t the thing for this lab.



Please make the root of the file name your login name. E.g., mine would be pnico.jpg.




GDB Tutorial.



Read and understand the Quick Introduction to GDB linked from the main cpe357 web page.




Once you have done this, write a small program, compile it, and run it within gdb. At the very least, you should




set a breakpoint by function name,



print the value of some variable in the function,



examine a backtrace to see how the function was called, and



step through a loop.



You might want to try this on the program from step 4.




Learn to use make(1).



You’ll want to do this in conjunction with step 4.




make(1) is a wonderful build-management tool that will help you keep your programs up to date while minimizing compile time by only recompiling those components for which it is necessary1. Besides, there is a direct benefit to this because every assignment from here on out will require you to submit a functional Makefile.




Your task:




That is, it will do that if you set up your dependencies correctly. If you get those wrong, you can be in for a world of hurt.



 














Read the Quick notes on make from the cpe357 web page.



Read and study the sample makefiles published with the solutions to Asgn1, also linked from the cpe357 page.



Write a small program—the one from step 4—and create a Makefile for it. This makefile must compile uniq when no argument is given to make, and support the following targets:



all Build the program. uniq Build the program.




testBuilds the program and runs it with a sample input. For example, it could run your uniq on a test file and compare the result to that produced by /bin/uniq




clean Removes all non-essential files generated during the build. Gener-ally this means the intermediate object (.o) files.




Your goals when writing this makefile should be to minimize the amount of duplication. That is, all, uniq, and test should not each have separate instructions for building the program. You should also make sure to include appropriate dependency information so that if one of your source files changes make will only recompile those files that need to be recompiled.




Bonus: Now—and only now—look into the man page for makedepend(1), but be warned: makedepend will include all the system files, too, making makefiles that are not portable. Clever application of the -Y option can get around this.




Program: uniq



This program is an exercise with dynamic data structures as a warm-up for Assignment 2.




Write a version of the unix utility program uniq(1). This program will act as a filter, removing adjacent duplicate lines as it copies its stdin to its stdout. That is, any line that is identical to the previous line will be discarded rather than copied to stdout.




Your program may not impose any limits on file size or line length.




To get started, I highly recommend writing a function char *read long line(FILE *file) that will read an arbitrarily long line from the given file into newly-allocated space. Once you have that, the program is easy.




Be careful to free memory once you are done with it. A memory leak could be a real problem for a program like this.




Note: even a utility as simple as this has decisions that must be made and specifications that must be negotiated. For example, a line that does not end with a newline is considered the same as one that does. From the specification2:




Also Note: For this, you may not use getline(3) or equivalent, since the whole point of the exercise is to learn to do dynamic memory management.







“The uniq utility shall read an input file comparing adjacent lines, and write one copy of each input line on the output. The second and succeeding copies of repeated adjacent input lines shall not be written. The trailing <newline> of each line in the input shall be ignored when doing comparisons.




“Repeated lines in the input shall not be detected if they are not adjacent.”







https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uniq.html
 














Tricks and Tools




There are some library routines with which you might want to be familiar before working on uniq listed in Figure 2.




 strlen(3)
calculate the length of a string




strcmp(3)
compare two strings




fgets(3)
read a string into a buffer (may or may not be of use to you here)




malloc(3)
allocate a given number of bytes of memory from the heap




realloc(3)
Change the size of a previously allocated chunk of memory




free(3)
return a malloc()ed region of memory to the heap







Figure 2: Some potentially useful commands and library functions







What to turn in




For the Written Problems: Include then in the a README file described below.




For the Laboratory Exercise: Submit via handin to the lab02 directory of the pn-cs357 ac-count:




your picture, named after yourself,



your well-documented source file(s) for uniq, and



A makefile (called Makefile) that will build uniq from your source when invoked either with no target or with the target “uniq”.



A README file that contains:



– Your name(s). In addition to your names, please include your Cal Poly login names with it, in parentheses. E.g. (pnico)




– Any special instructions for running your program.




– Any other thing you want me to know while I am grading it.




– The answers to the written questions above.




The README file should be plain text, i.e, not a Word document, and should be named “README”, all capitals with no extension.




















































4