Please answer the following questions and submit in your repo for the second assignment. Please keep the answers as short and concise as possible.
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**: Yes, externalizing `get_student(...)` into its own function improves the overall design of the database application. It enhances code modularity and reusability , reducing redundancy in functions like `del_student()` and `print_db()`.
>
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:
```c
intget_student(intfd,intid,student_t*s);
```
Notice that the last parameter is a pointer to storage **provided by the caller** to be used by this function to populate information about the desired student that is queried from the database file. This is a common convention (called pass-by-reference) in the `C` programming language.
In other programming languages an approach like the one shown below would be more idiomatic for creating a function like `get_student()` (specifically the storage is provided by the `get_student(...)` function itself):
```c
//Lookup student from the database
// IF FOUND: return pointer to student data
// IF NOT FOUND: return NULL
student_t*get_student(intfd,intid){
student_tstudent;
boolstudent_found=false;
//code that looks for the student and if
//found populates the student structure
//The found_student variable will be set
//to true if the student is in the database
//or false otherwise.
if(student_found)
return&student;
else
returnNULL;
}
```
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:** because the function returns a pointer to a local variable (`student`) . Once the function returns, the `student` variable goes out of scope , and the memory is deallocated , leading to undefined behavior . The returned pointer will point to invalid memory , potentially causing segmentation faults or unexpected behavior when accessed.
>
3. Another way the `get_student(...)` function could be implemented is as follows:
```c
//Lookup student from the database
// IF FOUND: return pointer to student data
// IF NOT FOUND or memory allocation error: return NULL
student_t*get_student(intfd,intid){
student_t*pstudent;
boolstudent_found=false;
pstudent=malloc(sizeof(student_t));
if(pstudent==NULL)
returnNULL;
//code that looks for the student and if
//found populates the student structure
//The found_student variable will be set
//to true if the student is in the database
//or false otherwise.
if(student_found){
returnpstudent;
}
else{
free(pstudent);
returnNULL;
}
}
```
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:**
>
```c
student_t*get_student(intfd,intid){
student_t*pstudent=malloc(sizeof(student_t));
if(pstudent==NULL)
returnNULL;
}
```
> works because the memory allocated via malloc() remains valid after the function returns. However, this introduces memory management issues:
>
> - The caller must free the allocated memory, or else it leads to memory leaks.
> - If the function is used frequently (e.g., in loops), unfreed memory accumulates, degrading performance.
> - Better alternative: The caller should allocate the structure and pass it as a pointer (which is the current implementation).
>
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:
```bash
> ./sdbsc -a 1 john doe 345
>ls-l ./student.db
-rw-r----- 1 bsm23 bsm23 128 Jan 17 10:01 ./student.db
>du-h ./student.db
4.0K ./student.db
> ./sdbsc -a 3 jane doe 390
>ls-l ./student.db
-rw-r----- 1 bsm23 bsm23 256 Jan 17 10:02 ./student.db
>du-h ./student.db
4.0K ./student.db
> ./sdbsc -a 63 jim doe 285
>du-h ./student.db
4.0K ./student.db
> ./sdbsc -a 64 janet doe 310
>du-h ./student.db
8.0K ./student.db
>ls-l ./student.db
-rw-r----- 1 bsm23 bsm23 4160 Jan 17 10:03 ./student.db
```
For this question I am asking you to perform some online research to investigate why there is a difference between the size of the file reported by the `ls` command and the actual storage used on the disk reported by the `du` command. Understanding why this happens by design is important since all good systems programmers need to understand things like how linux creates sparse files, and how linux physically stores data on disk using fixed block sizes. Some good google searches to get you started: _"lseek syscall holes and sparse files"_, and _"linux file system blocks"_. After you do some research please answer the following:
- 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:**
>
> The file size increases in multiples of 64 bytes (`sizeof(student_t)`) because each student record is stored at an offset of `id * 64` . For example:
> The actual file size includes gaps (due to `lseek()`), but Linux does not allocate storage for those gaps .
>
- 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:**
> Linux file systems allocate data in blocks (typically 4KB).
> When the database contained only small student IDs (≤ 63), all data fit within a single 4KB block.
> However, when we added ID=64, the file required more than 4KB, causing the system to allocate a second 4KB block.
>
- Now lets add one more student with a large student ID number and see what happens:
```bash
> ./sdbsc -a 99999 big dude 205
> ls -l ./student.db
-rw-r----- 1 bsm23 bsm23 6400000 Jan 17 10:28 ./student.db
> du -h ./student.db
12K ./student.db
```
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:**
>
> - `ls` reports logical file size , reflecting the highest byte written (`ID 99999 * 64B = 6.4MB`).
> - `du` reports actual storage used on disk. Since the file has large gaps due to `lseek()`, Linux does not allocate storage for empty spaces. Only actual stored student records consume space, leading to a real disk usage of just 12KB.
