Shtifting bug explanation

04_Memory_Management/05_Heap_Allocation.md

@@ -335,7 +335,7 @@ What the heap will look like after the code above?
 |  6 | F  | X  |  ..  |  X  | 6  | F  |  X | .. | X  | 6  | F  | .. | X  |    |    |
 
 
-Now, all of the memory in the heap is available to allocate (except for the overhead used to store the status of each chunk), and everything looks perfectly fine. But now the code keeps executing, and it will arrive at the following instruction:
+Now, all of the memory in the heap is available to allocate (except for the overhead used to store the status of each chunk), and everything looks perfectly fine. But the code keeps executing, and it will arrive at the following instruction:
 
 ```c
 alloc(7);
@@ -416,7 +416,7 @@ This means that the allocator (before marking this location as free and returnin
 
 ![The heap status after the merge](/Images/heap_example_after_merge.png)
 
-The fields in bold are the fields that are changed. The exact implementation of this code is left to the reader.
+The fields in bold are the fields that are changed. The exact implementation of this code is left to the reader. Please note that some books refers to this technique, calling it _coalescing_, but is the same concepts.
 
 ### Part 6: Splitting
 

08_VirtualFileSystem/03_TarFileSystem.md

@@ -97,7 +97,7 @@ The picture below show how data is stored into a tar archive.
 
 To move from the first header to the next we simply need to use the following formula:
 
-$$ next\_header = header\_ptr + header\_size + file\_size $$
+$$ next\_{header} = header\_{ptr} + header\_{size} + file\_{size} $$
 
 The lookup function then will be in the form of a loop. The first thing we'll need to know is when we've reached the end of the archive. As mentioned above, if there are two or more zero-filled records, it indicated the end. So while searching, we need to make sure that we keep track of the number of zeroed records. The main lookup loop should be similar to the following pseudo-code:
 

99_Appendices/C_Language_Info.md

@@ -96,6 +96,38 @@ It is worth mentioning that inline assembly syntax is the At&t syntax, so the us
 asm("movl $5, %rcx;");
 ```
 
+## Dealing With Literals and Bitwise Operation
+
+This is one of the most misleading and subtle issue we can face while osdeving. And most of the time we face it the hard way. 
+
+So what is the problem? let's imagine we have a 64 bit variable, and we need some to do a bitwise operation like `setting` the bit at the position `x`, this is easily achieved using the _left shift_ (`|=`) operator combined with a _xor_ (`|=`), like in the following pseudocode: 
+
+```
+variable example_var |= (1 << x)
+```
+
+And that is correct, and it probably could work in many languages (of course changing the syntax), but let's see what happens with C and C++ languages. 
+In _C_, the statement above become:
+
+```c
+uint64_t example_var |= (1 << x);
+```
+
+And we do few test, for `x=1, 2, 10, 20, 31`, everything works fine, so what is the issue? The issue is when the shift is above 31, because of the C _Integer promotion rule_.
+
+In the above example, `1` is a literal, and by default C converts it to `int`,  and this type in C is 32 bits, the bitwise operation is executed using the type of the left operand, so we are trying to shift left a bit of a number of position that is higher, than the size of the variable, causing an undefined behavior. 
+
+Then what are the solutions? Below few example of how to potentially fix it: 
+
+```c
+#define ONE 1ULL
+const uint64_t one = 1;
+
+uint64_t example_one |= one << 42;
+uint64_t example_two |= ONE << 42;
+uint64_t example_three |= 1ULL << 42;
+```
+
 ## C +(+) assembly together - Calling Conventions
 
 Different C compilers feature a number of [calling conventions](https://en.wikipedia.org/wiki/X86_calling_conventions),

99_Appendices/J_Updates.md

@@ -66,3 +66,4 @@ Sixth Book Release
 * _Stivale 2_ protocol sections have been replaced with Limine protocol, since _stivale2_ has been deprecated.
 * Add a complete exammple of how to create an ELF executable for our kernel
 * Typo and error fixes
+* New short paragraph to explain the behaviour of literals with bitwise operators.