CS 240 Summer 2025

Lab 6: Variadic functions and concurrent client/server app (260 pts)

Due: 07/30/2025 (Wed), 11:59 PM

Objective

The objective of this lab is to practice building variadic functions that take variable number of arguments, and code a simple concurrent client/server app which is the bread and butter software of the IT world. The Bonus Problem will go over the steps of creating a static library on our lab machines.


Reading

Read chapter 7 and 8 from K&R (textbook).


Lab 6 Code Base

The C code base for lab6 is available as a tarball

/homes/park/pub/cs240/lab6.tar

on the lab machines. The code in the subdirectories of lab6/ serve as coding exercises whose lessons and skills are utilized to solve this assignment.


Problems [260 pts]

Important: When implementing solutions for the problems, please only utilize techniques covered thus far in class. This is a constraint that requires one to work within the boundaries allowed by a given tool set. Invoking techniques including calls to library functions not covered in class will incur significant penalty points.

Problem 1 (120 pts)

Create v20/ and code a variadic function, char *myconcat(int, ...), in v20/myconcat.c where the first argument specifies the number of additional arguments to follow which should be all be of type, char *, containing strings. myconcat() concatenates the string arguments into a single string that is stored in heap memory using realloc(). myconcat() returns the address of the concatenated string. Use the man pages to determine how to use realloc(). Explain in lab6.pdf how you will be utilizing realloc() in your code and how it will suffice for the purpose of implementing myconcat(). myconcat() returns NULL if an error occurs. Describe in lab6.pdf what errors may arise in mycontact() that prompt returning NULL. Provide a 3-4 paragraph description in lab6.pdf of how to use your myconcat() directed at programmers who may consider using it (similar to a man page but not as rigorous and complete).

Code main() in v20/main.c to test myconcat(). Annote myconcat.c and main.c where the latter describes the different test cases/scenarios you evaluated your implementation of myconcat() on. Do not include a Makefile.

Problem 2 (140 pts)

Code a simple shell, minsh, in v21/ based on the code base lab6/v2 discussed in class that outputs a prompt of your choice to stdout and reads from stdin an executable followed by command-line arguments (if any) that are then executed using fork() and execvp(). minsh does not wait on the child process to finish executing the requested executable before printing a fresh prompt to stdout and to accept the next request. Instead minsh calls sleep(2) to rest for 2 seconds before starting all over by printing the prompt. Print prompts always on a separate line ending with space character ' '.

minsh supports five built-in commands:

'e': if the user enters character 'e' followed by ENTER/RETURN (i.e., '\n') the shell will call exit(0) and terminate.

'c' <string>: if the user enters character 'c' followed by one or more space or tab characters then a string (must be comprised only of alphanumeric ASCII characters, ':', '>', '@', '$', '%'), then your default prompt stored in a global variable, char prompt[12], is changed to the specified string. Since the maximum length of a prompt is 11 bytes (not counting '\0'), check that a prompt does not exceed 11 characters. If it does, output a suitable message to stdout and output a fresh prompt. The same applies if the string contains characters outside the allowed values.

'l': if the user enters character 'l' followed by ENTER/RETURN, it will be interpreted as an alias for the /bin/ls command.

'L': if the user enters character 'L' followed by ENTER/RETURN, it will be interpreted as an alias for the /bin/ls command with option '-l' (i.e., long output).

'j': if the user enters character 'j' followed by ENTER/RETURN, it will be run the /bin/cat command on the text file joke.dat that contains a joke (must be PG13 and wholesome) of your choice.

If a command does not match one of the four built-ins, we will let execvp() load and execute it, whether valid or invalid on our lab machines. Note that in minsh, a concurrent client/server multithreaded app, execvp() in a child may fail which must be appropriately handled as discussed in class.

How you code minsh, subject to only using techniques and library functions discussed in class (unless otherwise specified in the problem description), is up to you. Create a text file README where you describe the functions that you coded, their roles, and the names of files where they reside. Include a Makefile that automates compilation of your app. Test and verify that minsh works correctly.


Bonus problem (20 pts)

Create directory v22/ and copy the files from Problem 2, lab3. The procedure for creating static libraries is system dependent. In the Linux PCs in our lab, we will use the following steps. Create an initial archive by running

     ar rcs libfileproc.a readinput.o

which will add the object code of readinput() contained in readinput.o from Problem 2, lab3, to a newly created libfileproc.a. To list the content of the archive run

     ar t libfileproc.a

To add further object files to the archive, in our case, printoutput.o containing the compiled code of printoutput(), run

     ar rcs libfileproc.a printoutput.o

Regarding the option rcs, modifier r inserts an object file into the archive, replacing a previous version if one exists. The modifier c creates an archive if it doesn't exist. The s modifier maintains an object file symbol index which is needed for management purposes.

Perform the above steps manually to check that everything works as intended. After verifying correctness, modify the Makefile submitted in lab3 so that archive entries are automatically updated whenever object files are updated. Recall that actions (such as running gcc) after specifying a dependency which are updated based on time stamps as noted in class are added by inserting a tab followed by an action (in our case, ar with arguments). Test that the modified Makefile works correctly.

The Bonus Problem is entirely optional. Bonus points count toward reaching 35% of the course grade contributed by lab assignments.


Turn-in instructions

Electronic turn-in instructions:

i) For problems that require answering/explaining questions, submit a write-up as a pdf file called lab6.pdf. Place lab6.pdf in your directory lab6/. You can use your favorite editor subject to that it is able to export pdf files which many freeware editors do. Files submitted in any other format will not be graded. The TAs need to spend their time evaluating the content of your submission, not switching between editors or hunting down obscure document formats which wastes time and is in no one's interest.

ii) We will use turnin to manage lab assignment submissions. In the parent directory of lab6, run the command

turnin -c cs240 -p lab6 lab6

You can verify/list your submission by running: turnin -c cs240 -p lab6 -v. Please double-check that you submitted what you intended to submit.


Back to the CS 240 web page