Should Jae link to the recitation repository?

It equates a FILE* (the standard file stream handle) with a file descriptor, which makes it hard to explain how fdopen works. Should fix this definition and then explain what a file descriptor actually is.

This paragraph is not clear, even though it covers an important distinction:

"In most cases, just calling an array by its variable name without the square brackets will be interpreted as a pointer to the first element of the array. Incrementing a pointer will always move it ahead by the number of bytes making up the type to which it's pointing. In other words, incrementing a pointer makes the pointer move by the size of the type. In this case we're dealing with a pointer to an int, so the pointer will move by 4 bytes to the next int. Unlike a pointer, though, an array is a constant variable (see the code snippet above for how that affects p++ and a++)."

I'll try to find time for fixing this but if anyone else has time, please see if you can word it in a less confusing way!

I think we could create more coding "usable", standalone coding examples that students can clone and play around with. We can choose to use any number of them during our recitations to supplement our "lecturing" (i.e. reading off of notes), rather than talk about them abstractly as snippets embedded within our long-form notes.

Another side discussion is about whether or not we want to include Makefiles with those notes – on one hand, I think it's at least a common courtesy, and we should hold ourselves to our own standards as far as distributing code with Makefiles (plus, we can include cool alternative compilation rules, like make debug or make alternate which can define different pre-processor variables), but on the other hand, since this stuff is public, I'm wondering if security/giving away the answers is a problem.

What are your thoughts?

/K-File-IO/file-io.md states the following:

For example, after running the example above, echo < hi.txt will print "hello world" to the console.

Running this command produces the same output as echo with no arguments, instead of the expected output. A more suitable example might be cat < hi.txt ?

• In recitation 3 and 8 it should say 2^8 on line: "8 bits form a single byte: 11111111 = 2^7 - 1 = 255"
• In recitation 3 and 8 the line "(0177777 == -1); //returns 1 (true)" should be changed to use a 32-bit integer for this octal representation.
• In recitation 5, the sample code for a tree using the "Node" struct should use the reference operator, not the actual values.
• In recitation 4 code, strcpy function has an incorrect comment. p and p2 point one past the null at the end of the string by the end.
• There is a spelling error in recitation 2, digression section, first sentence, "grea"
• Recitation 4 code, increment incorrectly reports the final value

Should add something about ~ when talking about relative paths. This seems to be a point of confusion.

Jae uses sample code and separates them out. We should do the same otherwise recitation notes get too far ahead.

Can't you just directly modify the pointers of prevNode? Why do you need to search the list?

https://github.com/cs3157/recitations/blob/master/H-Linked-Lists/linked-lists.md#adding-a-node-after-another-node

Test 3, Case 1:
The line
Buffer now contains: world\0\0\0\0\0hello\n
should be
Buffer now contains: world\0\0\0\0\0hello\0

Many students remain confused about which to use. We should do a better job of explaining what's different between them.

So many people are super confused by sizeof, and use it where they shouldn't. for example, in place of strlen. It might help some to emphasize that sizeof is (normally ¹) an operator evaluated at compile time, and becomes a constant. So it doesn't know. See K&R pgs 135, and to a lesser extent 203, for more.

1. Note this breaks, slightly, with C99 variable length arrays where sizeof acts like an expression, not a constant. (invalid in the C++ spec as far as I can tell)

We should add discussion about the server/client TCP/IP diagram to these recitation notes.
It is really crucial for the students to understand this for lab6, 7

Additionally, notes L contains information about interprocess communication, which I don't believe we cover. I think that it should more generally move to cover tcp-serv, tcp-recv, the new way we're teaching these concepts.

We don't want any trouble now

Right now the gifs are sort of separate. It would be nice if we could reference and include them in the recitation note. Right now many students might not see the .gif or might struggle with understanding the animation.

Rewrite around Jae's shell.c sample code and lab5 skeleton code without other extraneous details.

Probably needs to be done for all recitation notes

we are missing this. We need more discussion on memory addresses and processes and adress space.

x = 5 x >> 1 should be 2, not 1

Peeps struggle with the HTTP spec - we should come up with an exercise or something to really drive home what's strict, and who can cheat and be ok.

Currently no examples of forking without if/else right afterward. It would be important to demonstrate that this is a possible use of fork in some way.

What do you guys think about this? I was thinking about this the other day and realized that for all the shifting around of existing topics we do it might just make more sense to split all the files out into their own topics. We could outline which topics would be covered which week in the README.md file instead.

Note H on reverseList:

Perhaps a simpler method is to create a temporary list. Traverse through the original list and then add each node to the front of the temporary list. The temporary list will be the reverse of the original list. Of course, there's an equivalent method that doesn't involve traversal, but still uses the same fundamental idea.

mylist.h in the lab skeleton:

Note that this function reverses the list purely by manipulating pointers. It does NOT call malloc directly or indirectly (which means that it does not call addFront() or addAfter()).

The current one is too complicated. There's a perfectly good one here. Need to decide whether to remove the current one completely (including from the code directory) or not.

In OH someone was having issues with their program, and they didn't find valgrind helpful. Well it turns out they were manually running gcc whatever.c and then just running ./a.out for testing. "I'll get to the makefile later." Of course without adding -g there were no debugging symbols, so the valgrind errors just had random hex garbage.

This suggests we should more comprehensively show an example of how much debugging symbols (and warnings) can help. Perhaps combine with the gdb example?

All the hyperlinks in the main README to "Recitation Note _" jump to a text file (that I have seen so far). That is, except for the link for section D. Not a major functionality issue, but I would expect that this isn't something too hard to fix.

strncpy(d, "456", 2); 

does not zero-terminate after copying "45" into d

Clarify what happens in each of the situations below.

MyString s1("hello");
MyString s2(s1);
MyString s3 = s1;
MyString s4;
s4 = s1;

The section in Notes K on FILE pointers and file descriptors needs to be rewritten. It's a jumbled mess that doesn't make the proper distinction between a file descriptor (the integer used by write, etc.) and a FILE pointer (the FILE * type used by fwrite, etc.).

This is a super confusing topic for students and our recitation notes need to be correct and precise. I don't have time to do it right now, but fixing this should be a very high priority.

size_t x = 5;
size_t y = 3;
int z = y - x;

-- reported as requested by Kevin during OH

I wrote "positive (1) or negative (0)". Sad!

GDB is not really covered in any of the earlier recitations. We should probably address this earlier on when students start debugging their first assignments.

See, for example, the email I wrote 5/6/2014, and many similar questions.

Dead link in J-Fork-Exec notes, section about "Communicating Between Processes", couldn't find any material on IPC in any of the notes

The myadd program in the makefile recitation has int argc, char **argv even though we have not covered it in class at this point. We found this after a student came to Jae's office hours confused about what it meant.

https://github.com/cs3157/recitations/blob/95bfc0042b438c41787528aea186f16d65e93b82/B-Makefiles/practice/myadd/main.c

The operator= has a line that takes &rhs, where rhs is a const MyString&

I think this is undefined in C++: http://stackoverflow.com/questions/3494458/memory-address-of-reference-variable

Jae's lecture notes don't mention it

Emily on #72:

As for pacing/structure, Unix2 would be hard to get through without a TA for now

https://github.com/cs3157/recitations/blob/master/D-Bits-Binary-C-Basics/bits-and-binary.md
Typos:

1. Shouldn't it be first "six" instead of "five" letter of alphabet?
2. In bitwise NOT ~, it takes "one" integer as operand.

Doubts:

1. In bitwise OR I, can the section include why we can't arrive at the same permission in more than 1 way?

Need a diagram for smart pointer illustrating memory.

Should probably explain much more. Including why the count needs to be on the heap.

Between Memory Errors and Lost Memory, there's this sentence:

The compiler won't warn you about it in any non-trivial case.

It seems that it should be "the compiler will warn you...".

Clarify that structs have padding, sizeof() ain't perfect.

If fopen() fails it will return a NULL pointer. This can happen because a file doesn't exist (in the case of r's and a's).

-- report as requested by Kevin during OH