Coding Standards}. We encourage you to follow the applicable parts of
them too, especially chapter 5, ``Making the Best Use of C.'' Using a
different style won't cause actual problems, but it's ugly to see
-gratuitous differences in style from one function to another.
+gratuitous differences in style from one function to another. If your
+code is too ugly, it will cost you points.
-Pintos comments sometimes refer to outside standards or
+Pintos comments sometimes refer to external standards or
specifications by writing a name inside square brackets, like this:
@code{[IA32-v3]}. These names refer to the reference names used in
this documentation (@pxref{References}).
+If you remove existing Pintos code, please delete it from your source
+file entirely. Don't just put it into a comment or a conditional
+compilation directive, because that makes the resulting code hard to
+read. We're only going to do a compile in the directory for the current
+project, so you don't need to make sure that the previous projects also
+compile.
+
@node Conditional Compilation
@section Conditional Compilation
specify for that part. @xref{Problem 1-4 Advanced Scheduler}, for
details.
+@item
+Problem 3-2, paging to and from disk. Your page replacement policy must
+default to LRU-like replacement, but we must be able to choose a random
+replacement policy with a compile-time directive. You must use the
+macro name we specify for that part. @xref{Problem 3-2 Paging To and
+From Disk}, for details.
+
@item
Code written for extra credit may be included conditionally. If the
extra credit code changes the normally expected functionality of the
@func{strlcpy}.
@item strcat
-Same issue as @func{strcpy}, but substitute @func{strlcat}.
+Same issue as @func{strcpy}. Use @func{strlcat} instead.
Again, refer to comments in its source code in @code{lib/string.c} for
documentation.