@@ -5,7 +5,7 @@ Please answer the following questions and submit in your repo for the second ass
1. In this assignment I asked you provide an implementation for the `get_student(...)` function because I think it improves the overall design of the database application. After you implemented your solution do you agree that externalizing `get_student(...)` into it's own function is a good design strategy? Briefly describe why or why not.
> **Answer**: _start here_
> **Answer**: Yes, I took SE and the main thing they taught us was single responsibility principle so it's great design choice, because it makes it really easy to change and understandble.
2. Another interesting aspect of the `get_student(...)` function is how its function prototype requires the caller to provide the storage for the `student_t` structure:
...
...
@@ -39,7 +39,7 @@ Please answer the following questions and submit in your repo for the second ass
```
Can you think of any reason why the above implementation would be a **very bad idea** using the C programming language? Specifically, address why the above code introduces a subtle bug that could be hard to identify at runtime?
> **ANSWER:** _start here_
> **ANSWER:** I think that student, is created and it's a pointer is never cleared before returning so it causes memory issues.
3. Another way the `get_student(...)` function could be implemented is as follows:
...
...
@@ -72,7 +72,7 @@ Please answer the following questions and submit in your repo for the second ass
```
In this implementation the storage for the student record is allocated on the heap using `malloc()` and passed back to the caller when the function returns. What do you think about this alternative implementation of `get_student(...)`? Address in your answer why it work work, but also think about any potential problems it could cause.
> **ANSWER:** _start here_
> I think making sure malloc works correctly is the only issue and also the pointer. Local pointers are alwas a risk I think.
4. Lets take a look at how storage is managed for our simple database. Recall that all student records are stored on disk using the layout of the `student_t` structure (which has a size of 64 bytes). Lets start with a fresh database by deleting the `student.db` file using the command `rm ./student.db`. Now that we have an empty database lets add a few students and see what is happening under the covers. Consider the following sequence of commands:
...
...
@@ -102,11 +102,11 @@ Please answer the following questions and submit in your repo for the second ass
- Please explain why the file size reported by the `ls` command was 128 bytes after adding student with ID=1, 256 after adding student with ID=3, and 4160 after adding the student with ID=64?
> **ANSWER:** _start here_
> **ANSWER:** Ls counts the file size with the memory allocated for it, like the empty spaces for new students. While Du doesn't account of that and only counts the students currently in.
- Why did the total storage used on the disk remain unchanged when we added the student with ID=1, ID=3, and ID=63, but increased from 4K to 8K when we added the student with ID=64?
> **ANSWER:** _start here_
> **ANSWER:** The file is farther down in blocks, because ID is used to calulate where the file goes in this position and this ID is way farther out so it has to create a path of blocks into it reaches that point.
- Now lets add one more student with a large student ID number and see what happens:
...
...
@@ -119,4 +119,4 @@ Please answer the following questions and submit in your repo for the second ass
```
We see from above adding a student with a very large student ID (ID=99999) increased the file size to 6400000 as shown by `ls` but the raw storage only increased to 12K as reported by `du`. Can provide some insight into why this happened?
> **ANSWER:** _start here_
\ No newline at end of file
> **ANSWER:** ls accounts for the blocks used. So if they're are 3 blocks being used, but only 1 of them are full then it only counts for the one block. But, du counts only counts the ones that are used so, the empty blocks are not accounted for.
