Update README.md

Author: mstern98

README.md

@@ -53,7 +53,7 @@ Debug
 
 # Errata
 ## Edge/vertex modification
-	Modifying/deleting vertices and edges inside f() not using submit request
+Modifying/deleting vertices and edges inside f() not using submit request
 can lead to undefined behavior or dead locks. This is because in CONTEXT
 set to SWITCH or NONE with many starting vertices, can lead to a structure
 being NULL’d with its lock destroyed while another thread is holding that lock
@@ -64,43 +64,43 @@ mitigate this problem, the client should use submit request which will handle
 the requests sequentially with destroying structures last.
 
 ## Graph modification
-	Trying to delete the graph while running will result in undefined behav-
+Trying to delete the graph while running will result in undefined behav-
 ior. Destroying the graph does not lock any thread and thus will cause race
 conditions. The graph should be deleted only once all threads reach a sink.
 
 ## Parameter Passing
-	Parameters passed to edges or vertices functions will be free’d immediately
+Parameters passed to edges or vertices functions will be free’d immediately
 after use and therefore will cause an error should they try and be accessed. To
 mitigate the values may be stored in the edge’s or vertex’s global or shared
 variables. Any non standard data type, such as struct, is dependent on the user
 to free its content as the library will only free the pointer to the struct and the
 pointer to the array of variables.
 
 ## Illegal Arguments
-	Passing wrong values or wrong number of variables to any function will result
+Passing wrong values or wrong number of variables to any function will result
 in failure. A client should be aware of which vertices connect and what edges
 it has and the proper handling required between such connections. Should the
 client choose to dynamically add/remove vertices or edges or even modify while
 running should be aware of the changes that may occur in the graph and the
 resulting change in dependence on proper variable handling.
 
 ## Graph Modification (cont.)
-	It is possible to modify the graph while it is running. To do so the client
+It is possible to modify the graph while it is running. To do so the client
 should submit request to add a change or pause the graph. Making any changes
 externally may result in undefined behavior if done improperly. Modifying the
 graph directly while running could result in failure.
 	Should the number of init vertex args not much the number of vertices in
 the start set the program will result in an error.
 
 ## Data Structure Errata
-	Stacks and AVLTree can take non malloc’d data and function normally
+Stacks and AVLTree can take non malloc’d data and function normally
 within scope of those non malloc’d data. However, in another scope the memory
 will be unaddressable and thus should be malloc’d memory instead. The stack
 and AVL Tree wll not free the void * data since the void * data structure is
 unknown to them and thus the client should free the memory.
 
 ## SWITCH_UNSAFE
-	Should SWITCH_USNAFE be used as the context, then the graph will run like
+Should SWITCH_USNAFE be used as the context, then the graph will run like
 how it runs in SWITCH, but the variables shared between the edge and the second vertex
 b will be passed to the edges function. Trying to read the shared variables may lead to a 
 race condition in which vertex b or one/some of it's edges are modifying those varibales.