Note that the GNU/Linux manpage for strtok claims that it uses a

[pintos-anon] / ta-advice / HW2

diff --git a/ta-advice/HW2 b/ta-advice/HW2
index 3e9b4ac49f679e0c8c773f48cf2c4639553d2487..95049b38e1a8b7b0bdcefa55a8a015f3ee14a1c8 100644 (file)
--- a/ta-advice/HW2
+++ b/ta-advice/HW2
@@ -102,6 +102,16 @@ A3:
           parsing.  This is wrong: it modifies the string provided and
           stores a pointer into it statically.
 
+          However, the manpage for on GNU/Linux (at least) says that
+          strtok uses a static buffer.  That's wrong.  So don't
+          penalize students who repeat that claim.  Instead, please
+          add a note, such as:
+
+             Although some manpages for strtok do claim that strtok
+             uses a static buffer, this is incorrect.  strtok uses a
+             user-provided buffer and statically stores a pointer
+             into that buffer.
+
 A4:
 
     Some correct answers:
@@ -657,3 +667,30 @@ B11:
     Take off points if an answer assumes that there can be more than
     one thread per process and doesn't mention that this would be an
     extension to the Pintos design.
+
+Check the submitted code, by hand, for the following:
+
+  1. That the system call handler, which is probably in
+     userprog/syscall.c in syscall_handler(), is reasonably
+     abstracted.  It should not all be in one function as one huge
+     switch statement, for example.  The code that accesses user
+     memory should be separated into specialized functions.  If either
+     of these is not the case, or if the code is otherwise difficult
+     to read, take off points.
+
+  2. The "Source Code" section in the Introduction to the Pintos
+     manual says, "Update existing comments as you modify code."  Most
+     students ignore this.  Check whether the comment on
+     process_wait() in process.c has been updated.  At a minimum, the
+     two final sentences ("This function will be implemented in
+     problem 2-2.  For now, it does nothing.") should have been
+     deleted.
+
+  3. Find the implementation of the "open" system call.  Verify that
+     all resources are released in error cases and that errors are
+     properly handled.  One particular problem can be malloc() failure
+     after a file is successfully opened--is the return value checked?
+     If so, is the file closed before returning an error?
+
+     (Failure to check malloc() is in the OVERALL section of the grade
+     report, under DESIGN.)