Announcements will appear for awhile on the course home page and then be archived here.

• 4 Apr. I just posted the notes and demos for lectures 17 and 18 to the usual places. (See Lecture Notes page.)

• 3 Apr. In today's lecture, I gave the piece of code:

  unsigned char ch;
  ch = getc( in );
  if (ch == EOF) {...}           
  

  and analyzed what happens on end-of-file. getc() returns -1, which becomes 255 when converted to an unsigned char. This case is indistinguishable from the case of successfully reading a byte of all 1's, which also has value 255, so this code does not do what was intended.

  Nevertheless, the question arose as to exactly what would happen. Here are the rules.

  1. EOF is #defined in stdio.h to be (-1).
  2. The constant 1 has type int.
  3. The expression -1 means to apply unary minus to 1. The result also has type int.
  4. The operands to == have types unsigned char and int, respectively. Since unsigned char is an unsigned type of less rank (shorter length) than the signed type int, the first operand is converted to the signed type (i.e., to type int).
  5. The conversion from unsigned char to int preserves the numerical value, since every number representable as an unsigned char (i.e., 0...255) is also representable as an int.
  6. The result of ch == EOF is always 0 (false) since all of the numbers 0...255 are different from -1.

  One correct way to read a byte into a variable of type unsigned char and also test for end of file is:

  unsigned char ch;
  int tmp;
  tmp = getc( in );
  ch = tmp;
  if (tmp == EOF) {...}
  

• 2 Apr. Deadlines extended: Because of the holidays and the length and complexity of both the current and the upcoming problem set, I have decided to give extra time to each.

  • The due date for PS7 is extended to Saturday, April 7 (before midnight).
  • PS8 will be due on Tuesday, April 17 (before midnight).

• 2 Apr. PS5 and PS6 have been graded. PS5 grade and comment sheets can be picked up from Pavel Dimitrov. PS6 grades and comments were emailed today.

• 31 Mar. I've coded up the many algorithms I described in Thursday's lecture for computing the XOR of the bits in a word and for counting the number of bits in a word. The programs are in the file bitops.c, which can be found on the Zoo in directory /c/cs223/lectures/demos_17/17.1_bitops/.

• 28 Mar. I just posted the notes and demos for lectures 15 and 16 to the usual places.

• 27 Mar. Problem set 7 (.pdf) is now available. It is due on Tuesday, Apr. 3. Files to accompany this assignment will be placed on the Zoo in /c/cs223/assignments/ps7.

• 6 Mar. A question on PS5 came up after class about whether startTower() should place the tower on the player's last position in that column or on the square following the last position. In other words, does startTower() implicitly do an advanceTower() or not? It could be done either way, so I'll decide that it should go on the previously-occupied position and not do an implicit advanceTower(). If one numbers the squares on the physical game board starting with 1, then we can use 0 for the column position of a player who has not yet made any progress on the column.

• 5 Mar. Late policy: Several people have asked me for an extension on the current problem set. My standard late policy is to accept submissions up to four days after the deadline with a late penalty of 5 points per day late (on a scale of 100). I will also waive the late penalty (and give a longer extension, if necessary) with a Dean's excuse. Please contact me if you expect to submit work more than four days after the due date.

• 5 Mar. Problem set 6 (.pdf) is now available. It is due on Tuesday, Mar. 27. Files to accompany this assignment are on the Zoo in /c/cs223/assignments/ps6.

• 5 Mar. When I wrote test_board.c (PS5), I had been assuming that a newly-created player would take over ownership of the string buffer nm; hence the buffer would be freed by freePlayer(). But this also meant that only dynamically-allocated strings could be used as the first argument to newPlayer(). That turned out to be a bad design choice. With the Mar. 4 correction below, freePlayer() no longer attempts to free nm, resulting in a memory leak in test_board.c. I have updated test_board.c to correct this problem.

• 4 Mar. Please ignore the comment in player.h (PS5) about nm being dynamically allocated. newPlayer() should malloc its own buffer and copy the string nm into it. Then it doesn't matter what kind of storage nm occupies. I'll edit player.h to remove that misleading comment.

• 3 Mar. For an example of how to use const in defining and implementing an interface (which is required for PS5), I have converted the stack example from the lecture 10 demo to use const. It defines const_stack and uses it in place of stack for the parameter type of those functions that only look at the stack but do not modify it. It's located in /c/cs223/lectures/demos_10/10.1_stack_with_const.

  You'll see that hardly anything needed to be changed other than the parameter types. The original implementation never did modify the stack except when necessary, so the only changes were to add qualifiers to make explicit which functions modify their arguments.

• 3 Mar. The header files for problem set 5 involve the const qualifier, which was only briefly mentioned in class. The new handout, Using const in C (.pdf), gives a more thorough explanation of how const works.

• 3 Mar. I fixed a minor bug in the header file util.h in /c/cs223/assignments/ps5. It now includes stdlib.h so that size_t will be defined when the prototypes are read. Without this change, things work fine if the client code happens to include stdlib.h before including util.h but not if it includes them in the other order. This kind of order dependency among includes should be avoided whenever possible.

• 26 Feb. I just posted a handout on Modules and Separate Compilation (.pdf). It should be a good review guide for the material presented in class on modules, compiling and linking, #include, and make.

• 25 Feb. Pavel Dimitrov will conduct a review session for the exam tomorrow evening, Monday, Feb. 26, at 7:30 pm in room AKW 200.

• 25 Feb. Information for Tuesday's midterm examination:

  • The exam will cover the following material:

    1. Topics covered in lectures 1-11 (through Tuesday, Feb. 20), posted class demos from same, and posted lecture notes.

    2. Problem sets 1-3, 4a, and 4b.

    3. Textbook, Chapters 1-3 and Sections 8.1-8.4.

    4. The concept of a linked list, as used in demos 11.1_stack and 11.2_queue and covered in the first part of textbook Section 9.5 (pages 391-394).

  • Here are the promised links to last year's midterm examination and solutions. Note that we're covering the topics in a slightly different order this year, so recursion will not be covered on this year's exam.

  • I am in the process of setting up a review session with the TA's for tomorrow evening (Monday, Feb. 26). I will announce the exact time and place once it's finalized.

• 23 Feb. I have finally posted problem set 5 (.pdf). It is due on Tuesday, Mar. 6. Files to accompany this assignment are on the Zoo in /c/cs223/assignments/ps5.

• 18 Feb. If you run unittest with a correct flexbuf implementation on a file that contains only a single 7-character partial line (i.e., no terminating new line character), unittest will give the spurious comment:
  
  Error: buffer size 16 too large for string size 8 (including null)
  
  It complains because it thinks a buffer of size 8 ought to be big enough. However, that's not true in this case. The reason is that after the first call to fgets(), the file has been completely read but fgetline() doesn't know this. The buffer has been completely filled and there is no terminating new line charcter, so fgetline() is forced to grow its buffer and call fgets() again in order to determine that indeed there is nothing more to read. This same situation will occur whenever the file ends in a partial line that exactly fills the buffer.

  I have posted a corrected unittest.c program in the PS4 course folder /c/cs223/assignments/ps4. However, if you have already submitted your program using the old version of unittest.c, you do not need to resubmit with the corrected version. No points will be deducted from your assignment for mistakes in my unit test program.

• 18 Feb. Notes for PS4b:

  1. The unittest command that results from compiling and linking unittest.c and your file flexbuf.c takes the name of a file as a command line argument. It opens the file and reads it twice using fgetline(). On the first pass, the same flexbuf is used for each line, which is accessed via toString(). On the second pass, each line is extracted from the flexbuf using extract(). On each pass, it performs a number checks and reports any errors it finds. Whether or not there are any errors, it prints out the length of the line in the buffer and the buffer length as reported by buflen(). It also compares the original file with the lines returned by fgetline() and prints out any differences it finds using the linux diff -c command.

  2. testflexbuf is a simple shell script for calling unittest on a suite of test files. It assumes the test files are all located in a subdirectory of the working directory called data and that all test files have file name extension .txt. If data doesn't exist or doesn't contain any .txt files, the original script gave an obscure error comment:
     set: No match.
     I have posted a revised test script that produces a more helpful comment in this case.

  3. When your program is done, you should submit all of the files necessary to build unittest (i.e., Makefile, flexbuf.h, flexbuf.c, and the unittest.c file that I supplied). You should also submit a file test.out that contains the output from running flexbuftest on the test files that I supplied.

     You may also submit additional test files along with the output of unittest when run on them if you can think of useful test cases that are not already covered by my test files.

  4. The number of this assignment for the submit command is "4b".

• 16 Feb. The notes and demo from this past week are now available. They can be found in the usual place. Note that the version of the stack demo code presented in class was not robust and could lead to memory corruption if an empty stack were ever popped. The version presented here has been fixed. See the readme file for explanation of some new C features that I used in the modified code.

• 14 Feb. The midterm exam will be on Tuesday, February 27 at the regular class time and place.

• 13 Feb. Important notice. I have been persuaded by multiple requests to extend the due date for PS4a by one day to midnight, Wednesday, Feb. 14. The deadline for PS4b remains midnight, Tuesday, Feb. 20. Good luck!

• 12 Feb. The long-awaited unit test program and test script are now available in the PS4 course folder /c/cs223/assignments/ps4. These are only needed for part (b) of the assignment, which is not due until Feb. 20. I've also added two files increasing.txt and decreasing.txt to the data directory that are particularly helpful during the early stages of debugging flexbuf. Please note that there is an empty line at the beginning of increasing.txt and at the end of decreasing.txt.

  This test code should be considered a work in progress. Please let me know if it reports errors in code that you think is correct and I'll either try to clear up your misunderstanding or fix the bug in the test code. Those of you who like recursive thinking can consider the problem of writing a unit test program to test the unit test program!

• 12 Feb. Two clarifications about the specification for parfill in PS4a:

  1. Although initial whitespace on a line should be preserved, this does not apply to the '\n' character that terminates a line, even though '\n' is indeed considered to be whitespace. I regard the '\n' as a line separator that does not belong to any line, so it should always be removed.

  2. If one or more characters follow the last '\n' in a file, those characters are said to comprise a partial line, which should be treated like any other line of the file. However, if the last character of the file is '\n', then no partial line is present. Thus, a file with k '\n' characters contains k lines if nothing follows the last '\n' and k+1 lines otherwise.

  Note that it is not safe to simply remove any terminating '\n' from the input line before processing it, for a line that contains a single '\n' is an empty line that should result in an empty line of output, whereas a line that contains no characters at all should be ignored. Once the '\n' is gone, these two cases become indistinguishable.

• 11 Feb. I've placed some sample data files for PS4a in the course folder /c/cs223/assignments/ps4/data. The input files end in .txt, and the corresponding formatted versions end in .fmt. The formatted files have each output line enclosed in square brackets so that you can more easily see where the blanks are in each line. This will be useful for you to do while debugging your code as well, but of course the brackets should not appear in your final output.

• 8 Feb. I posted a new handout giving an overview of the C storage model (.pdf). It covers the topics of today's lecture in much greater detail than I was able to give in class. It also covers the important function free() and gives much more information about the three distinct storage areas available to a C program: static, stack, and heap.

• 8 Feb. Important notice. Now that I know what I was and was not able to cover in today's lecture, I have decided to split PS4 into two pieces:

  1. (Due Tuesday, Feb. 13): Implement parfill. Submit as assignment number 4a.
  2. (Due Tuesday, Feb. 20): Implement the flexbuf module and test it with the yet-to-be-supplied unit test main program and script. Submit as assignment number 4b.

  Because you will need flexbuf in order to write parfill, I have placed header and object files for a working flexbuf module in the course directory /c/cs223/assignments/ps4. I've compiled it for i386, x86_64, and ppc architectures. You should copy the header file and the correct object code file for your machine over to your own directory and use them from there. (The Zoo uses the i386 architecture.) Good luck!

• 8 Feb. I just made extensive revisions to problem set 4 (.pdf). In addition to the changes mentioned yesterday, I have simplified the return value from fgetline(), and I have modified how parfill should behave. I also corrected an important error where I describe how to print only some of the characters in a string. The format should be "%.*s"; I had omitted the dot.

  The corrected handout is #7 (v.2) (.pdf). If you printed out the original version, please discard it and use the corrected version instead. I'm sorry for making so many changes after the assignment was issued, but I learned a lot when solving it myself.

• 7 Feb. Here are a few additions to problem set 4 (.pdf):

  1. flexbuf should support a function

     int buflen( flexbuf fb );

     that returns the current length of the buffer. This number is the allocation size of the buffer, not the length of the string currently stored in the buffer (which could be shorter).

  2. I failed to specify precisely how the character buffer should grow. When first created, it should be 8 bytes long. Every time it needs to be expanded, its length should double.

  3. fgetline() should only expand the buffer when it is full and the current input line is not yet complete. Thus, if fgetline() is called when the flexbuf is not empty, it should first call fgets() with the current size of the buffer. Only if the line is not complete after this call returns should be buffer be expanded.

  These changes do not yet appear in the PS4 assignment handout. I will update it once I am a bit more confident that there won't be further changes.

• 7 Feb. I just posted problem set 4 (.pdf). It is due on Tuesday, Feb. 13. The unit test program and script referenced in the handout is not yet ready. I will put it in directory /c/cs223/assignments/ps4 when ready.

• 4 Feb. I've updated the Lecture Notes page. It now has links to all lecture notes and all demos to date. I will endeavor to make lecture notes and demos available as soon as possible after class, but I can't always promise to have it done immediately. When I post new notes or demos, I will add links to the Lecture Notes page, but I might not always announce it here. In any case, you can always look at the Zoo directory /c/cs223/lectures where they live to see what is available.

• 2 Feb. The results you get from running your variance program on the data file test.in depend on the computer architecture. I have now run my solution on three different architectures: i386 (Zoo machines), x64_64 (AMD machines and newer Intel 64-bit machines), and ppc (old Macs), and gotten three different results. I have replaced test.out with three files giving the results on each of these three architectures: test.out.i386, test.out.x86_64, and test.out.ppc. It's possible that the results will vary also according to the compiler optimization level and which compiler you are using. How much roundoff error occurs depends on details of the floating point unit and exactly what code is compiled. For example, some floating point units contain more bits of internal precision than can be stored externally. Depending on the compiled code, they may perform a sequence of computations before storing the result back to memory (and therefore incur less roundoff error). However, I can't explain why compiling it on my x86_64 machine in 32-bit mode (using the compiler flag -m32) seems to result in greater accuracy than when using 64-bit mode. (The results in 32-bit mode are the same as I get on an i386 architecture machine.) I'd love to hear if anyone has an explanation for this.

• 1 Feb. I put a small data file test.in and the corresponding output file test.out for problem set 3 into the Zoo directory /c/cs223/assignments/ps3. This data is by no means an adequate test of your program, but it should give you an idea of the kind of behavior to expect from your program.

• 31 Jan. I just posted problem set 3 (.pdf). It is due on Tuesday, Feb. 6.

• 30 Jan. Some new lecture notes and demos are in the usual place. Also, handout 5 (.pdf) on integer types in C is available.

• 28 Jan. I just corrected an error in problem set 2: Section 1.3 part 3 should refer to dice.c and dice.o rather than to group.c and group.o. The corrected handout is #4 (v.2) (.pdf).

• 23 Jan. The other TA for this course, Yinghua, Wu, has just returned from China. Welcome back, Yinghua! She will be holding office hours on WF 3:30-5 pm. Pavel will hold offices hours MTh 3:30-5 pm as previously announced. Yinghau and Pavel will alternate helping students in the Zoo on Tuesday evenings 7-9 pm. The updated office hours schedule is in the box at the bottom of this page.

• 22 Jan. I've put sketchy nodes for lecture 1 and lecture 2 on the web site. They may also be found on the Zoo in the directory /c/cs223/lectures.

  These notes are in emacs "outline" format. If you are viewing them in emacs, go into "outline" mode with the command "M-x outline-mode" and the different levels of the outline will be displayed in different colors. There are also a number of commands for opening and closing sublevels and navigating around the outline.

• 22 Jan. The TA, Pavel Dimitrov, has scheduled office hours: M 3:30-5 pm, Tu 7:00-9 pm, Th 3:30-5 pm. See below for his office location and phone number.

• 21 Jan. I posted two new handouts. Handout 3 (.pdf) contains the rules to the game Can't Stop. This is the focus of problem set 2 (.pdf) as well as later problems. Problem set 2 is due on Tuesday, January 30. An executable file for my solution to problem set 2 is posted in /c/cs223/assignments/ps2 which you can use to get a better idea of how your code is supposed to work. However, I don't promise my code to be bug-free, so if you find bugs, please tell me but don't imitate them in your own code.

• 19 Jan. I've put the demos from lecture 2 on the web site. The files are also available directly on the Zoo at /c/cs223/lectures/demos_02. Included with each project are makefiles for use in automatically building the project. To play with the demos, copy them to your own directory, go into one of the project subdirectories, and type make. We'll talk more about makefiles, but this should get you started. Mac users who have Xcode installed will find an xcode project file in the xproj subdirectory.

• 18 Jan. I've patched the submit script so that it no longer excludes executable files. For those of you who have already submitted, please try again. And thanks for pointing out the problem so promptly. Much better for me to know now than the night the assignment is due!

• 16 Jan. Problem set 1 (.pdf) is available. It is due on Tuesday, January 23. You will need to have a Zoo account and a CPSC 223b course directory in order to do this problem. See the syllabus for information on signing up for a Zoo account.

• 5 Jan. Welcome to the CPSC 223b web site. Look here for announcements and course materials.