nit: bold not italics

initial-reverse/README.md

@@ -1,7 +1,7 @@
 
 # Introduction
 
-*Before beginning:* Read this [lab tutorial](lab-tutorial.pdf); 
+**Before beginning:** Read this [lab tutorial](lab-tutorial.pdf); 
 it has some useful tips for programming in the C environment.
 
 This project is a simple warm-up to get you used to how this whole
@@ -53,10 +53,10 @@ the output file the user supplies.
 When invoked with just one command-line argument, the user supplies the input
 file, but the file should be printed to the screen. In Unix-based systems,
 printing to the screen is the same as writing to a special file known as
-*standard output*, or `stdout` for short.
+**standard output**, or `stdout` for short.
 
 Finally, when invoked without any arguments, your reversing program should
-read from *standard input* (`stdin`), which is the input that a user types in,
+read from **standard input** (`stdin`), which is the input that a user types in,
 and write to standard output (i.e., the screen).
 
 Sounds easy, right? It should. But there are a few details...
@@ -65,31 +65,31 @@ Sounds easy, right? It should. But there are a few details...
 
 ## Assumptions and Errors
 
-- *Input is the same as output:* If the input file and output file are the
+- **Input is the same as output:** If the input file and output file are the
 same file, you should print out an error message "Input and output file must
 differ" and exit with return code 1.
 
-- *String length:* You may not assume anything about how long a line should
+- **String length:** You may not assume anything about how long a line should
 be. Thus, you may have to read in a very long input line...
 
-- *File length:* You may not assume anything about the length of the
-file, i.e., it may be *VERY* long.
+- **File length:** You may not assume anything about the length of the
+file, i.e., it may be **VERY** long.
 
-- *Invalid files:* If the user specifies an input file or output file, and
+- **Invalid files:** If the user specifies an input file or output file, and
 for some reason, when you try to open said file (e.g., `input.txt`) and
 fail, you should print out the following exact error message: `error:
 cannot open file 'input.txt'` and then exit with return code 1 (i.e., call
 `exit(1);`).
 
-- *Malloc fails:* If you call `malloc()` to allocate some memory, and
+- **Malloc fails:** If you call `malloc()` to allocate some memory, and
 malloc fails, you should print the error message `malloc failed` and exit
 with return code 1.
 
-- *Too many arguments passed to program:* If the user runs `reverse`
+- **Too many arguments passed to program:** If the user runs `reverse`
 with too many arguments, print `usage: reverse <input> <output>` and exit with
 return code 1. 
 
-- *How to print error messages:* On any error, you should print the
+- **How to print error messages:** On any error, you should print the
 error to the screen using `fprintf()`, and send the error message to
 `stderr` (standard error) and not `stdout` (standard output). This
 is accomplished in your C code as follows: 
@@ -120,7 +120,7 @@ information on malloc.
 
 ## Tips
 
-*Start small, and get things working incrementally.* For example, first
+**Start small, and get things working incrementally.** For example, first
 get a program that simply reads in the input file, one line at a time, and
 prints out what it reads in. Then, slowly add features and test them as you
 go.
@@ -131,14 +131,14 @@ out. Then, we wrote code to store each input line into a linked list and made
 sure that worked. Then, we printed out the list in reverse order. Then we made
 sure to handle error cases. And so forth...
 
-*Testing is critical.* A great programmer we once knew said you have to
+**Testing is critical.** A great programmer we once knew said you have to
 write five to ten lines of test code for every line of code you produce;
 testing your code to make sure it works is crucial. Write tests to see if your
 code handles all the cases you think it should. Be as comprehensive as you can
 be. Of course, when grading your projects, we will be. Thus, it is better if
 you find your bugs first, before we do.
 
-*Keep old versions around.* Keep copies of older versions of your program
+**Keep old versions around.** Keep copies of older versions of your program
 around, as you may introduce bugs and not be able to easily undo them. A
 simple way to do this is to keep copies around, by explicitly making copies of
 the file at various points during development. For example, let's say you get