Here are some comments on things the TA noticed while marking the first assignment. There are important things to note here that you should apply to the subsequent assignments where marks will be lost.

1. For part (2). It is important to have a separate pipe for communication between the parent and each child. See the solution which implements the code in this way.

The reason for this is that pipes are not meant to be written by multiple processes. There is a single buffer in the kernel to hold the contents of the transmitted data. With sufficient traffic, if two or more processes try to write to a pipe then the data they are writting will appear interleaved and garbled. For e.g one given two processes P1 and P2 that write out streams of 'a\na\n' and 'b\nb\nb\n' a seeminlgly random arrangment of a's and b's will appear at the output. Simply because P1 writes for a while, then P2 etc.. If you are transmitting strings of numbers such as '123456789123456789' and '1111111111' you may get something like '12341111111111156789111111'.

This data corruption is not apparent in the assignments because the amount of data transmitted by each child is very small. This means the child is almost always able to send all it's data as one atomic chunk, before the next child is scheduled to run.

For anything more complicated, the return data from all the child processes would be mixed up almost randomly, which is not a good thing.

2. It is extremely important to be paranoid in your programming. When you make a system call, check the return value for the error case. Several assignments did not check if fork failed. Yes it really can fail.

Even though this was a short assignment, you should get used to the idea of checking all your assumptions. In a larger project this can make a tremendous difference in how fast you determine the cause of problems with your code.

On a similar note, several people were lax in their input validation. It really doesn't take that much more effort to ensure that input is valid. Some marks were deducted for these points on A1, but many more will be deducted in subequent assignments.

One useful thing to know about is the assert(3) function. This can be used to assert that your assumptions at the start of a function are indeed true, e.g. you have a function that inserts an element in a list:

#include <assert.h>
void insert_element(node_t* node, int new_key)
{
	assert(node !=NULL);  //this checks that node is initialized
		   	      //if not your program will terminate
			      //telling you which assertion failed,
			      //and on what line.
	....
}

See the man page for more details.
3. User friendly assignments. The user in this case is your TA. Sample run:

%part1
Segmentation fault

I should not have to read the source to figure out you want the input passed on the command line. If input is not entered in the expected form your program should display usage information.

Also see (2), if no parameters have been passed on the command line then don't try to access the corresponding non-existant elemnents of argv[]!

4. The sqrt(n) issue - not really an OS issue. If you want to compute the factors, then using a list up to sqrt(n) requires some extra work. See the solution source files. Some assignments used lists up to sqrt(n) but didn't do the extra work needed. This is wrong, you can miss factors in this way.
5. Functions. A few people had much of their code in main() and Erastothenes(). The only reason this was accepted is because the code in main was fairly short. It is very important for the code to be modularized into separate short functions that do one thing and one thing only. In all subsequent assignments marks will be deducted for non-modular code.