1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
How to review a patch
=====================
Some folks have said that they'd like to review patches more often, but they
don't know how.
So, here are a bunch of things to check for when reviewing a patch!
Note that if you can't do every one of these, that doesn't mean you can't do
a good review! Just make it clear what you checked for and what you didn't.
Top-level smell-checks
----------------------
(Difficulty: easy)
- Does it compile with `--enable-fatal-warnings`?
- Does `make check-spaces` pass?
- Does `make check-changes` pass?
- Does it have a reasonable amount of tests? Do they pass? Do they leak
memory?
- Do all the new functions, global variables, types, and structure members have
documentation?
- Do all the functions, global variables, types, and structure members with
modified behavior have modified documentation?
- Do all the new torrc options have documentation?
- If this changes Tor's behavior on the wire, is there a design proposal?
- If this changes anything in the code, is there a "changes" file?
Let's look at the code!
-----------------------
- Does the code conform to CodingStandards.txt?
- Does the code leak memory?
- If two or more pointers ever point to the same object, is it clear which
pointer "owns" the object?
- Are all allocated resources freed?
- Are all pointers that should be const, const?
- Are `#defines` used for 'magic' numbers?
- Can you understand what the code is trying to do?
- Can you convince yourself that the code really does that?
- Is there duplicated code that could be turned into a function?
Let's look at the documentation!
--------------------------------
- Does the documentation confirm to CodingStandards.txt?
- Does it make sense?
- Can you predict what the function will do from its documentation?
Let's think about security!
---------------------------
- If there are any arrays, buffers, are you 100% sure that they cannot
overflow?
- If there is any integer math, can it overflow or underflow?
- If there are any allocations, are you sure there are corresponding
deallocations?
- Is there a safer pattern that could be used in any case?
- Have they used one of the Forbidden Functions?
(Also see your favorite secure C programming guides.)
|
