From cd9d9341290979c2e7bf2e531e2189b84b841182 Mon Sep 17 00:00:00 2001
From: Ziheng Chen <zc328@dragons.drexel.edu>
Date: Sun, 2 Feb 2025 22:22:07 +0000
Subject: [PATCH] Replace a2-questions.md

---
 w4hw/a2-questions.md | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/w4hw/a2-questions.md b/w4hw/a2-questions.md
index 3e9d602..ea69fd8 100644
--- a/w4hw/a2-questions.md
+++ b/w4hw/a2-questions.md
@@ -6,7 +6,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**: 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()`.
+   > **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:
 
@@ -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:** 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.
+   > **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:
 
@@ -117,7 +117,7 @@ Please answer the following questions and submit in your repo for the second ass
 
      > **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 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:
      >
      > - `ID=1 → Offset 1 * 64 = 64 (next multiple: 128B)`
      > - `ID=3 → Offset 3 * 64 = 192 (next multiple: 256B)`
@@ -148,5 +148,3 @@ Please answer the following questions and submit in your repo for the second ass
      > - `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.
      >
-
-     
-- 
GitLab