lostecho/ostep-projects
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

nit: bold not italics

Browse Source
This commit is contained in:
Remzi Arpaci-Dusseau
2019-02-21 12:19:36 -06:00
parent a972c1e594
commit 8b574b3adb
1 changed files with 14 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
initial-reverse/README.md
View File

@@ -1,7 +1,7 @@
# Introduction # 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. 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 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 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, 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 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 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). and write to standard output (i.e., the screen).
Sounds easy, right? It should. But there are a few details... 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 ## 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 same file, you should print out an error message "Input and output file must
differ" and exit with return code 1. 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... 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 length:** You may not assume anything about the length of the
file, i.e., it may be *VERY* long. 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 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: 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 cannot open file 'input.txt'` and then exit with return code 1 (i.e., call
`exit(1);`). `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 malloc fails, you should print the error message `malloc failed` and exit
with return code 1. 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 with too many arguments, print `usage: reverse <input> <output>` and exit with
return code 1. 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 error to the screen using `fprintf()`, and send the error message to
`stderr` (standard error) and not `stdout` (standard output). This `stderr` (standard error) and not `stdout` (standard output). This
is accomplished in your C code as follows: is accomplished in your C code as follows:
@@ -120,7 +120,7 @@ information on malloc.
## Tips ## 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 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 prints out what it reads in. Then, slowly add features and test them as you
go. 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 that worked. Then, we printed out the list in reverse order. Then we made
sure to handle error cases. And so forth... 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; 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 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 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 be. Of course, when grading your projects, we will be. Thus, it is better if
you find your bugs first, before we do. 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 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 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 the file at various points during development. For example, let's say you get