Q.2

m21

In for(Init; Cond; Upd):   Upd part is not executed when the loop is entered for the first time.

m22

In for(Init; Cond; Upd):   Init part is ONLY executed when the loop is entered for the first time.

m23

Wrong evaluation of &&. (Result is ALWAYS 1 or 0; x&&y=1 if and only if BOTH x and y are nonzero.)

m24

Wrong evaluation of ||. (Result is ALWAYS 1 or 0; x&&y=1 if and only if AT LEAST ONE OF x and y is nonzero.)

m25

The C statement
   n=j||n
is an assignment, not a branching operator. After evaluation of the right-hand side, the obtained value (0 or 1) must be assigned to the variable n in the left-hand side. The RHS can be evaluated (by hand) as a boolean value (True or False) or as an integer value (1 or 0), but the resulting value of n will be 1 or 0 in any case.

m26

Exiting loop while condition is still true. (If, in line 12 of the given code, you find that (j<n) is true, you must continue with the loop).

m27

Wrongly presumed initialization: If nothing is said about the initial value of a variable, then such a variable will have an undefined (unpredictable) value up until it first appears in the left-hand side of an assignment.

Q.3

m31

Incorrect treatment of function's argument: in line 17 the value of j is considered as argument of f. (It is a mistake to pass the value 90 to the function when i=65 and j=90). Similar error in line 22.

m32

In line 17: The computed value of f is not assigned to j. Correct treatment: if you found that f returns 63 in line 104, then j becomes 63 as the last action in line 17. Similarly in line 22, where the value returned from f is assigned to i.

m33

Wrong evaluation of the boolean value(65%2 !=0). Argue as follows: since 65%2=1, therefore (65%2 !=0) equals (1!=0), which is True (indeed, 1 is not equal to 0).

m34

Most of the students who (by mistake) came to consider Case 2, didn't notice that the order the variables j, i in the output list in printf (line 21) doesn't match the text printed by the printf statement. For example, if the current values are i=65, j=90, then the iutput from line 21 is
      
Case2: i=90, j=65 printf There was a "reciprocal" mistake as well: a student noticed the wrong order of the variables, but assumed that their subsequent values are those printed (i=90, j=65 in the above example). However, the program doesn't understand the text we put in printf statements. Values of a variable can only change if that variable is assigned a new value. (For that, the variable must be found in the left-hand side of an assignment operator (or a shorthand like i++) or as an passed-by-reference argument of a function.)

m35

Output from line 103 in the body of f is not shown.

Q.4

In total, about 40 corrections could be suggested. All but one have been noticed by somebody in this class. The most subtle corrections are: initialization of longNFac (line 13b in my solution), the non-strict inequality in the loop condition j<=n (line 14), and the explicit int-to-double cast suggestion (line 16 of solution). The latter (a minor issue, in fact) was not marked by anyone. All in all, the collective expertise of this class in scrutinizing the code by hand proved to be 99% satisfactory.

Remarks/misunderstandings:

m41

Line 9: It is syntaxically correct and not so bad from the style point of view. The programmer didn't implement the validation section of the code, but (s)he left a remark (/*stub*/). This remark would better be smth like /*Place validation here*/ or return(1), or a complete validation code (print error message and return). Removing the braces related to if or putting them around the next line or a few lines makes the problem worse.

m42

Line 23: There is no then keyword in C.

m43

Line 3: While the suggestion to move the opening brace to next line is good, it should be given as a mild recommendation. Correctness of the code doesn't depend on this. In fact, some programmers adopt a style of putting opening braces on the same line with opening keywords. That is, the consistently write   int main(){..,  if(..){..,    for(..;..;..){.., etc. I personally think this makes the code a bit less readable (because it is more difficult to match opening and closing braces visually). On the other hand, it saves one line of code per brace.

m44

Line 24: the standalone unary operator --l is absolutely equivalent to l--. The difference only pops up when such an operator is a part of a longer statement, cf. Textbook, p.88.)

m45

Lines 9-10. A suggestion like "Line 10 should include an else  statement to end the if-else construction" didn't earn a point. It is possible but unnecessary to put the tail of the code (from line 11 on) into an else clause.

m46

Lines 10-11. It is not necessary to terminate a comment on line end. Multi-line comments are valid. On the other hand, I accepted a suggestion to align the text in lines 10 and 11.

m47

A suggestion to include more blank lines in the code did not earn a point. While blank lines can indeed improve readability, they are not an issue in the proposed program.

m48

Line 8: The n= in scanf will not be printed. Use printf for a prompt.

m49

Line 14: This should be a for loop. Making it a correct do-construction needs a significant effort; you have to move all the three parts from the brackets to appropriate separate lines.