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.
 
           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:
 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.
     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.)