Blog

The University of Queensland School of Information Technology and Electrical Engineering CSSE2310/CSSE7231 — Semester 1, 2022 Assignment 3 (version 1.0) Marks: 75 (for CSSE2310), 85 (for CSSE7231) Weighting: 15% Due: 4:00pm Friday 13 May, 2022 Introduction 1 The goal of this assignment is to demonstrate your skills and ability in fundamental process management and 2 communication concepts, and to further develop your C programming skills with a moderately complex program. 3 You are to create two programs – the first is called sigcat which is like the Unix utility cat, however it 4 has enhanced signal handling functionality. The second, and major program, is called hq, and it is used to 5 interactively spawn new processes, run programs, send and receive output and signals to those process, and 6 manage their lifecycle. The assignment will also test your ability to code to a programming style guide, to use 7 a revision control system appropriately, and document important design decisions (CSSE7231 only). 8 Student Conduct 9 This is an individual assignment. You should feel free to discuss general aspects of C programming and 10 the assignment specification with fellow students, including on the discussion forum. In general, questions like 11 “How should the program behave if 〈this happens〉 ” would be safe, if they are seeking clarification on the 12 specification. 13 You must not actively help (or seek help from) other students or other people with the actual design, structure 14 and/or coding of your assignment solution. It is cheating to look at another student’s assignment code 15 and it is cheating to allow your code to be seen or shared in printed or electronic form by others. 16 All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or 17 collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if 18 you share your code with a friend, even inadvertently, then both of you are in trouble. Do not post your 19 code to a public place such as the course discussion forum or a public code repository, and do not allow others 20 to access your computer – you must keep your code secure. 21 Uploading or otherwise providing the assignment specification or part of it to a third party including online 22 tutorial and contract cheating websites is considered misconduct. The university is aware of these sites and 23 they cooperate with us in misconduct investigations. 24 You must follow the following code referencing rules for all code committed to your SVN repository (not 25 just the version that you submit): 26 Code Origin Usage/Referencing Code provided to you in writing this semester by CSSE2310/7231 teaching staff (e.g. code hosted on Black- board, posted on the discussion forum, or shown in class). May be used freely without reference. (You must be able to point to the source if queried about it.) Code you have personally written this semester for CSSE2310/7231 (e.g. code written for A1 reused in A3) May be used freely without reference. (This assumes that no reference was required for the original use.) Code examples found in man pages on moss. May be used provided the source of the code is referenced in a comment adjacent to that code. Code you have personally written in a previous enrolment in this course or in another ITEE course and where that code has not been shared or published. Code (in any programming language) that you have taken inspiration from but have not copied. Other code – includes: code provided by teaching staff only in a previous offering of this course (e.g. previous A1 solu- tion); code from websites; code from textbooks; any code written by someone else; and any code you have written that is available to other students. May not be used. If the source of the code is referenced adjacent to the code then this will be considered code without academic merit (not misconduct) and will be removed from your assignment prior to marking (which may cause compilation to fail). Copied code without adjacent referencing will be considered misconduct and action will be taken. 27 6959462-30065-6649710 The course coordinator reserves the right to conduct interviews with students about their submissions, for 28 the purposes of establishing genuine authorship. If you write your own code, you have nothing to fear from this 29 process. If you are not able to adequately explain your code or the design of your solution and/or be able to 30 make simple modifications to it as requested at the interview, then your assignment mark will be scaled down 31 based on the level of understanding you are able to demonstrate. 32 In short – Don’t risk it! If you’re having trouble, seek help early from a member of the teaching staff. 33 Don’t be tempted to copy another student’s code or to use an online cheating service. You should read and 34 understand the statements on student misconduct in the course profile and on the school web-site: https: 35 //www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism 36 Specification – sigcat 37 sigcat reads one line at a time from stdin, and immediate writes and flushes that line to an output stream. 38 The output stream by default is stdout, however the output stream can be changed at runtime between stdout 39 and stderr by sending sigcat the SIGUSR1 and SIGUSR2 signals. 40 Full details of the required behaviour are provided below. 41 Command Line Arguments 42 Your program (sigcat) accepts no commandline arguments. 43 ./sigcat 44 Any arguments that are provided can be silently ignored. 45 sigcat basic behaviour 46 Upon starting, sigcat shall enter an infinite loop reading newline-terminated lines from standard input, and 47 emitting them to an output stream. It is assumed that the data read from standard input is non-binary, i.e. 48 does not contain null () characters. 49 At program start, the output stream is to be standard output stdout. 50 sigcat shall remain in this loop until it receives end of file on stdin. 51 Upon reaching EOF on stdin, sigcat shall exit with exit code 0. 52 No further error checking is required in sigcat. 53 sigcat signal handling 54 sigcat shall register a handler or handlers for all signals of numeric value 1 through to 31 inclusive – except 9 55 (KILL) and 19 (STOP) which are not able to be caught. 56 Upon receiving a signal, sigcat is to emit, to the current output stream, the following text: 57 58 sigcat received 59 where is replaced with the signal name as reported by strsignal() (declared in ). 60 Note that this line is terminated by a newline and sigcat must flush its output buffer after every emitted line 61 of text. 62 Examples include: 63 sigcat received Quit sigcat received Hangup The signals SIGUSR1 and SIGUSR2 have special meaning to sigcat. After printing the output as specified 64 above, upon receipt of either of these signals sigcat shall further 65 set its output stream to standard output (stdout) if SIGUSR1 is received 66 set its output stream to standard error (stderr) if SIGUSR2 is received 67 In this way, sigcat can be instructed to direct its output to either stdout or stderr by sending it the 68 appropriate signals. 69 6959462-30065-6649710 Specification – hq 70 hq reads commands from its standard input one line at a time. All of hq’s output goes to stdout– and all 71 commands are terminated by a single newline. The commands are documented below, and allow the user to 72 run programs, send them signals, manage their input and output streams, report on their status and so on. 73 Full details of the required behaviour are provided below. 74 Command Line Arguments 75 hq accepts no commandline arguments. 76 ./hq 77 Any arguments that are provided may be silently ignored. 78 hq basic behaviour 79 hq prints and flushes a prompt “> ” (greater than symbol followed by a single space) to stdout then waits to 80 read a command from stdin. 81 The following table describes the commands that must be implemented by hq, and their syntax. Additional 82 notes on each command will follow. 83 Command Usage Comments spawn spawn [][] … Run in a new process, optionally the with ar- guments provided. Arguments or program names containing spaces may be quoted in double quotes. The new process’s stdin and stdout must be connected to hq by pipes, so that they can be accessed with the send and rvc commands. The new process’s stderr should be unchanged. report report [] Report on the status of or all jobs if no argumentprovided signal signal Send the signal ( – an integer) to the given job() sleep sleep Cause hq to sleep for the number of seconds specified. may be fractional, e.g. sleep 1.5 send send Send to the job. Strings containing spaces must bequoted with double quotes rcv rcv Attempt to read one line of text from the job specified anddisplay it to hq’s stdout eof eof Close the pipe connected to the specified job’s stdin, thus caus-ing that job to receive EOF on its next read attempt. cleanup cleanup Terminate and reap all child processes spawned by hq by sendingthem signal 9 (SIGKILL). 84 The following apply to all command handling and inputs: 85 Upon reaching EOF on stdin, hq shall terminate and clean up any jobs (see the cleanup command 86 below), and exit with status 0. 87 hq shall block or otherwise ignore SIGINT (Control-C). 88 Any invalid commands provided to hq (i.e. a word at the start of a line is not one of the above) shall 89 result in the following message to stdout: 90 Error: Invalid command Note that empty input lines (user just presses return) shall just result in the prompt being printed again. 91 All commands have a minimum number of arguments (possibly zero such as for report and cleanup). 92 If this minimum number of arguments is not provided, the following error message shall be emitted to 93 standard output: 94 Error: Insufficient arguments 6959462-30065-6649710 Extraneous arguments, if provided, shall be silently ignored. 95 All numerical arguments, if present, must be complete and valid numbers. e.g. “15” is a valid integer, 96 but “15a” is not. Similarly, “2.7” is a valid floating point value, but “2.7foobar” is not. Your program 97 must correctly identify and report invalid numerical arguments (see details below for each command). 98 Any text arguments, including strings and program names, may contain spaces if the argument is sur- 99 rounded by double quotation marks, e.g. “text with spaces”. A helper function is provided to assist 100 you with quote-delimited parsing, see the “Provided Library” section on page 9 for usage details. 101 One or more spaces may be present before the command and there may be more than one space between 102 arguments. The provided helper function will deal with this for you. 103 Where a command takes a jobID argument then a valid jobID is the ID of any job created using spawn– 104 even if the execution failed or the job has exited. 105 spawn 106 The spawn command shall cause hq to fork() a new process, setup pipes such that the child’s stdin and 107 stdout are directed from/to hq, and exec() the requested program. The $PATH variable is to be searched for 108 executable programs. 109 Each spawned process is to be allocated an integer job identifier (jobID), starting from zero. Jobs are created 110 and job IDs should increment even if the exec() call fails. 111 hq should emit the following to stdout: 112 New Job ID [N] created where N is replaced by the integer value, e.g. 113 New Job ID [34] created If at least one argument is not provided (the program name), then spawn shall emit the following message: 114 Error: Insufficient arguments If the exec() call fails then your child process is to exit with exit status 99. 115 report 116 The report command shall output information on all jobs spawned so far, with a header row and in the following 117 format: 118 > report [Job] cmd:status [0] cat:running [1] ls:exited(0) [2] sleep:signalled(9) … The cmd field shall be the name of the job (the value of the first argument given to the spawn command). 119 The status field shall be one of running – if the job has not yet exited; exited – if the job has terminated 120 normally – with the exit status shown in parentheses; or signalled – if the job terminated due to a signal – 121 with the signal number shown in parentheses. Jobs are to be reported in numerical order. 122 report may optionally take a single integer argument, which is a job ID. If provided, and valid, then only 123 the status of that job shall be reported. (The header line is also output.) 124 > report 1 [Job] cmd:status [1] ls:exited(0) If an invalid job ID is provided (i.e. non-numerical value or job was never spawned), then an error message 125 is to be emitted to standard output as demonstrated below: 126 6959462-30065-6649710 > report 45 Error: Invalid job > report abc Error: Invalid job signal 127 The signal command shall cause a signal to be sent to a job. Exactly two integer arguments must be specified 128 – the target job ID, and the signal number. If fewer arguments are provided, the following error is emitted: 129 Error: Insufficient arguments If the job ID is invalid, emit: 130 Error: Invalid job If the signal number is invalid (non-numeric, less than 1 or greater than 31): 131 Error: Invalid signal If all arguments are valid, the signal shall be sent to the targetted job. (There is no need to check whether 132 the job is still running.) 133 sleep 134 The sleep command shall cause the hq program to sleep for the number of seconds specified in its single 135 mandatory argument. Non-integer numbers, such as 1.5, are considered valid1. 136 If no duration is provided, emit the error message: 137 Error: Insufficient arguments If a negative or non-numerical duration is provided, emit the error message to stdout: 138 Error: Invalid sleep time send 139 The send command shall send a single line of text, whose contents are the second argument to the command, to 140 the identified job. Send requires exactly two arguments, the job ID and the string to be sent. Because arguments 141 are separated by spaces, to send a line containing spaces, the text must be contained in double quotes. A helper 142 function is provided to assist you with quote-delimited parsing, see see the “Provided Library” section on page 143 9 for usage details. 144 If less than two arguments are provided, send shall emit: 145 Error: Insufficient arguments If an invalid job ID is provided, emit the error message: 146 Error: Invalid job Example of usage: 147 > send 0 “hello job, quotes matter!” > send 2 textwithoutspaces > send 1 “” > send 4 text with spaces but these extra words are all ignored It is possible that the receiving process has exited – it is your job to manage any SIGPIPE signals so that 148 your program does not terminate in this situation. You are not required to detect or report if a job specified in 149 a send command is in this state – simply ensure that hq continues to run. 150 1The strtod() function may prove useful here 6959462-30065-6649710 rcv 151 rcv shall attempt to read one line of text from the identified job, and print it to standard output. One mandatory 152 argument is required – the job ID. If not specified, then emit 153 Error: Insufficient arguments If an invalid job ID is specified, emit 154 Error: Invalid job rcv must not block if there is no output available from the job. To facilitate this, a helper function 155 is_ready() is provided – see the “Provided Library” section on page 9. 156 If there is no output available to read from the job, rcv shall emit 157 If end-of-file is (or has previously been) received from the pipe connected to the job, then rcv shall emit 158 Otherwise, rcv shall emit to standard output, the line of text read from the job, e.g. 159 > rcv 0 Hello from the job! eof 160 The eof command shall close the stdin of the given job. One mandatory argument is required – the job ID. If 161 not specified, then emit 162 Error: Insufficient arguments If an invalid job ID is specified, eof shall emit 163 Error: Invalid job If the job ID is valid, hq does not output anything. 164 cleanup 165 The cleanup command shall send the SIGKILL (numerical value 9) signal to all jobs and wait() on them to 166 reap zombies. 167 Example hq Sessions 168 1 $ ./hq 2 > spawn cat /etc/resolv.conf 3 New Job ID [0] created 4 > report 5 [Job] cmd:status 6 [0] cat:exited(0) 7 > rcv 0 8 # Generated by NetworkManager 9 > rcv 0 10 search labs.eait.uq.edu.au eait.uq.edu.au 11 > rcv 0 12 nameserver 130.102.71.160 13 > rcv 0 14 nameserver 130.102.71.161 15 > rcv 0 16 6959462-30065-6649710 17 > send 0 foobar 18 > send 0 “anybody there ” 19 > rcv 0 20 21 > Even though the cat process has exited almost immediately, its output has been buffered in the connecting 169 pipe and can still be read. Note also that the send command is sending down a pipe that has nothing listening 170 on the other end. The kernel will be sending SIGPIPE to hq but these are being handled / ignored. 171 In the next example, we spawn a process running cat which will be expecting input on stdin, and sending 172 it back to stdout. hq can be used to manage this with the send and rcv commands: 173 1 $ ./hq 2 > spawn cat 3 New Job ID [0] created 4 > report 5 [Job] cmd:status 6 [0] cat:running 7 > rcv 0 8 9 > send 0 “hello world” 10 > rcv 0 11 hello world 12 > report 13 [Job] cmd:status 14 [0] cat:running 15 > send 0 “line 1” extra args 16 > send 0 “line 2” 17 > rcv 0 18 line 1 19 > rcv 0 20 line 2 21 > Next we illustrate the use and effects of the signal command: 174 1 $ ./hq 2 > spawn cat 3 New Job ID [0] created 4 > report 5 [Job] cmd:status 6 [0] cat:running 7 > signal 0 9 8 > report 9 [Job] cmd:status 10 [0] cat:signalled(9) All of these examples had only a single job, however hq must be able to keep an arbitrary number of jobs in 175 flight at once: 176 1 $ ./hq 2 > spawn cat /etc/services 3 New Job ID [0] created 4 > spawn cat /etc/passwd 5 New Job ID [1] created 6 > spawn cat 7 New Job ID [2] created 8 > report 9 [Job] cmd:status 10 [0] cat:running 11 [1] cat:exited(0) 6959462-30065-6649710 12 [2] cat:running 13 > rcv 0 14 # /etc/services: 15 > send 2 “hello world” 16 > rcv 1 17 root:x:0:0:root:/root:/bin/bash 18 > rcv 2 19 hello world 20 > rcv 2 21 22 > eof 2 23 > rcv 2 24 25 > report 26 [Job] cmd:status 27 [0] cat:running 28 [1] cat:exited(0) 29 [2] cat:exited(0) In this example, jobs 0 and 1 were simply catting files. Job 1 ran and terminated almost immediately, but 177 job 0 did not because the file being cat’ed was larger than the pipe buffer so cat was blocked on output. Job 178 2 was a cat blocking on standard input, and we interacted with it using send and rcv. We then send job 2 an 179 end-of-file with the eof command, and confirmed using report that job 2 had now also exited, having come to 180 end of file on input. 181 Here is an example of hq and sigcat interacting: 182 1 > spawn ./sigcat 2 New Job ID [0] created 3 > send 0 “Hello sigcat” 4 > rcv 0 5 Hello sigcat 6 > signal 0 1 7 > rcv 0 8 sigcat received Hangup 9 > signal 0 12 10 > signal 0 1 11 > sigcat received Hangup 12 rcv 0 13 sigcat received User defined signal 2 14 > report 15 [Job] cmd:status 16 [0] ./sigcat:running There are some very important subtleties demonstrated in this example: 183 We spawn the sigcat process (line 1), send it some text (line 3) and then read it back (lines 4 & 5). 184 We then send it signal 1 (SIGHUP) on line 6, and read back the output triggered by that signal (lines 7 & 185 8). Remember that by default, sigcat emits its output to stdout, which is captured by hq and accessible 186 only via the rcv command. 187 on line 9, we send signal 12 (SIGUSR2), which causes sigcat to emit the signal message to stdout, but 188 then switch its output stream to stderr . 189 When we then resend signal 1 (line 10), the output message from sigcat (underlined here) appears imme- 190 diately on the console – because it’s emitted over stderr and this stream is not captured by hq. 191 There is no prompt before the input on line 12 because the prompt is shown on line 11 (it was output 192 before the message to stderr). 193 6959462-30065-66497108 Provided Library: libcsse2310a3 194 A library has been provided to you with the following functions which your program may use. See the man 195 pages on moss for more details on these library functions. 196 char* read_line(FILE *stream); 197 The function attempts to read a line of text from the specified stream, allocating memory for it, and returning 198 the buffer. 199 char* is_ready(int fd); 200 This function will detect if there is any data available to read on the specified file descriptor, returning 0 (no 201 input) or 1 (input available) accordingly. You will need to use this to prevent your rcv command blocking. 202 char** split_space_not_quote(char *input, int *numTokens); 203 This function takes an input string and tokenises it according to spaces, but will treat text within double quotes 204 as a single token. 205 To use the library, you will need to add #include to your code and use the compiler flag 206 -I/local/courses/csse2310/include when compiling your code so that the compiler can find the include 207 file. You will also need to link with the library containing this function. To do this, use the compiler arguments 208 -L/local/courses/csse2310/lib -lcsse2310a3. 209 Style 210 Your program must follow version 2.2.0 of the CSSE2310/CSSE7231 C programming style guide available on 211 the course Blackboard site. 212 Hints 213 1. You may wish to consider the use of the standard library functions strtod(), strtol(), strsignal() 214 and usleep() or nanosleep(). 215 2. While not mandatory, the provided library functions will make your life a lot easier – use them! 216 3. The standard Unix tee command behaves like cat, but also writes whatever it receives on stdin to a 217 file. This, combined with watch -n 1 cat in another terminal window, may be very helpful 218 when trying to figure out if you are setting up and using your pipes correctly. 219 4. Review the lectures/contacts from weeks 5 and 6. These cover the basic concepts needed for this assign- 220 ment and the code samples may be useful. 221 Suggested Approach 222 It is suggested that you write your program using the following steps. Test your program at each stage and 223 commit to your SVN repository frequently. Note that the specification text above is the definitive description 224 of the expected program behaviour. The list below does not cover all required functionality. 225 1. Write sigcat first. It will be useful for testing hq later. 226 2. Write small test programs to figure out the correct usage of the system calls required for each hq command 227 – i.e. how to connect both stdin and stdout of a child process to pipes and manage access to them from 228 the parent. 229 3. Prototype the overall command loop of hq first, and work out how to parse input lines into tokens. You 230 can then implement each command (spawn, report etc) incrementally, using knowledge you gained from 231 step 2 above. 232 Forbidden Functions 233 You must not use any of the following C functions/statements. If you do so, you will get zero (0) marks for the 234 assignment. 235 goto 236 6959462-30065-6649710 longjmp() and equivalent functions 237 system() 238 mkfifo() or mkfifoat() 239 Submission 240 Your submission must include all source and any other required files (in particular you must submit a Makefile). 241 Do not submit compiled files (e.g. .o files and compiled programs). 242 Your programs (named sigcat and hq) must build on moss.labs.eait.uq.edu.au with: 243 make 244 Your programs must be compiled with gcc with at least the following options: 245 -pedantic -Wall -std=gnu99 246 You are not permitted to disable warnings or use pragmas to hide them. You may not use source files other 247 than .c and .h files as part of the build process – such files will be removed before building your program. 248 The default target of your Makefile must cause both programs to be built2. 249 If any errors result from the make command (i.e. no executable is created) then you will receive 0 marks 250 for functionality (see below). Any code without academic merit will be removed from your program before 251 compilation is attempted (and if compilation fails, you will receive 0 marks for functionality). 252 Your program must not invoke other programs or use non-standard headers/libraries. 253 Your assignment submission must be committed to your subversion repository under 254 https://source.eait.uq.edu.au/svn/csse2310-sem1-sXXXXXXX/trunk/a3 255 where sXXXXXXX is your moss/UQ login ID. Only files at this top level will be marked so do not put source 256 files in subdirectories. You may create subdirectories for other purposes (e.g. your own test files) but these 257 will not be considered in marking – they will not be checked out of your repository. 258 You must ensure that all files needed to compile and use your assignment (including a Makefile) are commit- 259 ted and within the trunk/a3 directory in your repository (and not within a subdirectory) and not just sitting 260 in your working directory. Do not commit compiled files or binaries. You are strongly encouraged to check out 261 a clean copy for testing purposes. 262 To submit your assignment, you must run the command 263 2310createzip a3 264 on moss and then submit the resulting zip file on Blackboard (a GradeScope submission link will be made 265 available in the Assessment area on the CSSE2310/7231 Blackboard site)3. The zip file will be named 266 sXXXXXXX_csse2310_a3_timestamp.zip 267 where sXXXXXXX is replaced by your moss/UQ login ID and timestamp is replaced by a timestamp indicating 268 the time that the zip file was created. 269 The 2310createzip tool will check out the latest version of your assignment from the Subversion repository, 270 ensure it builds with the command ‘make’, and if so, will create a zip file that contains those files and your 271 Subversion commit history and a checksum of the zip file contents. You may be asked for your password as 272 part of this process in order to check out your submission from your repository. 273 You must not create the zip file using some other mechanism and you must not modify the zip file prior 274 to submission. If you do so, you will receive zero marks. Your submission time will be the time that the file 275 is submitted via GradeScope on Blackboard, and not the time of your last repository commit nor the time of 276 creation of your submission zip file. 277 We will mark your last submission, even if that is after the deadline and you made submissions before the 278 deadline. Any submissions after the deadline4 will incur a late penalty – see the CSSE2310/7231 course profile 279 for details. 280 2If you only submit an attempt at one program then it is acceptable for just that single program to be built when running make. 3You may need to use scp or a graphical equivalent such as WinSCP, Filezilla or Cyberduck in order to download the zip file to your local computer and then upload it to the submission site. 4or your extended deadline if you are granted an extension. 6 959462-30065-6649710 0 Marks 281 Marks will be awarded for functionality and style and documentation. Marks may be reduced if you are asked 282 to attend an interview about your assignment and you are unable to adequately respond to questions – see the 283 Student conduct section above. 284 Functionality (60 marks) 285 Provided your code compiles (see above) and does not use any prohibited statements/functions (see above), and 286 your zip file has been generated correctly and has not been modified prior to submission, then you will earn 287 functionality marks based on the number of features your program correctly implements, as outlined below. 288 Partial marks will be awarded for partially meeting the functionality requirements. Not all features are of equal 289 difficulty. If your program does not allow a feature to be tested then you will receive 0 marks for 290 that feature, even if you claim to have implemented it. For example, if your program can never create a child 291 process (job) then we can not test your communication with that job. If your program takes longer than 15 292 seconds to run any test, then it will be terminated and you will earn no marks for the functionality associated 293 with that test. The markers will make no alterations to your code (other than to remove code without academic 294 merit). 295 Marks will be assigned in the following categories. 296 1. sigcat correctly copies its input to stdout (3 marks) 297 2. sigcat correctly outputs messages upon receiving signals (3 marks) 298 3. sigcat correctly changes output streams upon receipt of SIGUSR1 and SIGUSR2 (4 marks) 299 4. hq correctly rejects invalid commands (3 marks) 300 5. hq correctly implements spawn command (6 marks) 301 6. hq correctly implements report command (7 marks) 302 7. hq correctly implements sleep command (4 marks) 303 8. hq correctly implements send command (6 marks) 304 9. hq correctly implements eof command (3 marks) 305 10. hq correctly implements rcv command (6 marks) 306 11. hq correctly implements signal command (4 marks) 307 12. hq correctly implements cleanup command (4 marks) 308 13. hq correctly handles SIGPIPE and SIGINT as appropriate (2 marks) 309 14. hq frees all allocated memory prior to exit (5 marks) 310 Some functionality may be assessed in multiple categories, e.g. the ability to tokenise strings containing spaces 311 and within quotes. 312 Style Marking 313 Style marking is based on the number of style guide violations, i.e. the number of violations of version 2.2 of 314 the CSSE2310/CSSE7231 C Programming Style Guide (found on Blackboard). Style marks will be made up of 315 two components – automated style marks and human style marks. These are detailed below. 316 You should pay particular attention to commenting so that others can understand your code. The marker’s 317 decision with respect to commenting violations is final – it is the marker who has to understand your code. To 318 satisfy layout related guidelines, you may wish to consider the indent(1) tool. Your style marks can never be 319 more than your functionality mark – this prevents the submission of well styled programs which don’t meet at 320 least a minimum level of required functionality. 321 You are encouraged to use the style.sh tool installed on moss to style check your code before submission. 322 This does not check all style requirements, but it will determine your automated style mark (see below). Other 323 elements of the style guide are checked by humans. 324 6 959462-30065-6649710 1 All .c and .h files in your submission will be subject to style marking. This applies whether they are 325 compiled/linked into your executable or not5. 326 Automated Style Marking (5 marks) 327 Automated style marks will be calculated over all of your .c and .h files as follows. If any of your submitted 328 .c and/or .h files are unable to be compiled by themselves then your automated style mark will be zero (0). 329 (Automated style marking can only be undertaken on code that compiles. The provided style.sh script checks 330 this for you.) 331 If your code does compile then your automated style mark will be determined as follows: Let 332 W be the total number of distinct compilation warnings recorded when your .c files are individually built 333 (using the correct compiler arguments) 334 A be the total number of style violations detected by style.sh when it is run over each of your .c and 335 .h files individually6. 336 Your automated style mark S will be 337 S = 5 (W +A) 338 If W +A ≥ 5 then S will be zero (0) – no negative marks will be awarded. Note that in some cases style.sh 339 may erroneously report style violations when correct style has been followed. If you believe that you have been 340 penalised incorrectly then please bring this to the attention of the course coordinator and your mark can be 341 updated if this is the case. Note also that when style.sh is run for marking purposes it may detect style 342 errors not picked up when you run style.sh on moss. This will not be considered a marking error – it is your 343 responsibility to ensure that all of your code follows the style guide, even if styling errors are not detected in 344 some runs of style.sh. 345 Human Style Marking (5 marks) 346 The human style mark (out of 5 marks) will be based on the criteri