Fix formating issues

Author: tarunbhm

not-so-smart-contracts/ton/README.md

@@ -14,10 +14,10 @@ Each _Not So Smart Contract_ consists of a standard set of information:
 
 ## Vulnerabilities
 
-| Not So Smart Contract                                                        | Description                                                  |
-| ---------------------------------------------------------------------------- | ------------------------------------------------------------ |
-| [Int as Boolean](int_as_boolean)                                             | Unexpected result of logical operations on the int type      |
-| [Fake Jetton contract](fake_jetton_contract)                                 | Any contract can send a `transfer_notification` message      |
+| Not So Smart Contract                        | Description                                             |
+| -------------------------------------------- | ------------------------------------------------------- |
+| [Int as Boolean](int_as_boolean)             | Unexpected result of logical operations on the int type |
+| [Fake Jetton contract](fake_jetton_contract) | Any contract can send a `transfer_notification` message |
 
 ## Credits
 

not-so-smart-contracts/ton/fake_jetton_contract/README.md

@@ -3,7 +3,7 @@
 TON smart contracts use the `transfer_notification` message sent by the receiver's Jetton wallet contract to specify and process a user request along with the transfer of a Jetton. Users add a `forward_payload` to the Jetton `transfer` message when transferring their Jettons, this `forward_payload` is forwarded by the receiver's Jetton wallet contract to the receiver in the `transfer_notification` message. The `transfer_notification` message has the following TL-B schema:
 
 ```
-transfer_notification#7362d09c query_id:uint64 amount:(VarUInteger 16) 
+transfer_notification#7362d09c query_id:uint64 amount:(VarUInteger 16)
                               sender:MsgAddress forward_payload:(Either Cell ^Cell)
                               = InternalMsgBody;
 ```
@@ -27,14 +27,14 @@ The following simplified code highlights the lack of token_id validation in the
     slice sender_address = cs~load_msg_addr(); ;; incorrectly assumed to be Jetton wallet contract owned by this contract
 
     (cell token0_balances, cell token1_balances) = load_data(); ;; balances dictionaries
-    
+
     (int op, int query_id) = in_msg_body~load_op_and_query_id();
 
     if (op == op::transfer_notification) {
         (int amount, slice from_address) = (in_msg_body~load_coins(), in_msg_body~load_msg_addr());
         cell forward_payload_ref = in_msg_body~load_ref();
         slice forward_payload = forward_payload_ref.begin_parse();
-        
+
         int is_token0? = forward_payload.load_int(1);
 
         if (is_token0?) {

not-so-smart-contracts/ton/int_as_boolean/README.md

@@ -1,6 +1,6 @@
 # Using int as boolean values
 
-In FunC, booleans are represented as integers; false is represented as 0 and true is represented as -1 (257 ones in binary notation). 
+In FunC, booleans are represented as integers; false is represented as 0 and true is represented as -1 (257 ones in binary notation).
 
 Logical operations are done as bitwise operations over the binary representation of the integer values. Notably, The not operation `~` flips all the bits of an integer value; therefore, a non-zero value other than -1 becomes another non-zero value.
 
@@ -69,6 +69,7 @@ The following simplified code highlights the unexpected behavior of the `~` oper
 ```
 
 The `recv_internal` function above prints the following debug logs:
+
 ```
     #DEBUG#: correct_true is true
     #DEBUG#: ~correct_true is false
@@ -80,7 +81,7 @@ The `recv_internal` function above prints the following debug logs:
     #DEBUG#: ~negative is true
 ```
 
-It demonstrats that the `~ 10` and `~ -10` both evaluate to `true` instead of becoming `false` with the `~` operator. 
+It demonstrats that the `~ 10` and `~ -10` both evaluate to `true` instead of becoming `false` with the `~` operator.
 
 ## Mitigations