Merge pull request #945 from Denton-L/fix-documentation

Minor corrections to documentation

docs/contracts.rst

@@ -25,7 +25,7 @@ API, this is done as follows::
 
     // Need to specify some source including contract name for the data param below
     var source = "contract CONTRACT_NAME { function CONTRACT_NAME(unit a, uint b) {} }";
-    
+
     // The json abi array generated by the compiler
     var abiArray = [
         {
@@ -932,10 +932,11 @@ encoding of the address of the library contract.
 
 Restrictions for libraries in comparison to contracts:
 
-- no state variables
+- No state variables
-- cannot inherit nor be inherited
+- Cannot inherit nor be inherited
+- Cannot recieve Ether
 
-(these might be lifted at a later point)
+(These might be lifted at a later point.)
 
 .. index:: ! using for, library
 

docs/control-structures.rst

@@ -127,11 +127,11 @@ Those names will still be present on the stack, but they are inaccessible.
 
 .. _creating-contracts:
 
-Creating Contracts via new
+Creating Contracts via ``new``
-==========================
+==============================
 
 A contract can create a new contract using the ``new`` keyword. The full
-code of the contract to be created has to be known and thus recursive
+code of the contract being created has to be known and, thus, recursive
 creation-dependencies are now possible.
 
 ::
@@ -142,6 +142,8 @@ creation-dependencies are now possible.
             x = a;
         }
     }
+
+
     contract C {
         D d = new D(4); // will be executed as part of C's constructor
 
@@ -503,9 +505,9 @@ The opcodes ``pushi`` and ``jumpdest`` cannot be used directly.
 +-------------------------+------+-----------------------------------------------------------------+
 | callvalue               |      | wei sent together with the current call                         |
 +-------------------------+------+-----------------------------------------------------------------+
-| calldataload(p)         |      | call data starting from position p (32 bytes)                   |
+| calldataload(p)         |      | calldata starting from position p (32 bytes)                    |
 +-------------------------+------+-----------------------------------------------------------------+
-| calldatasize            |      | size of call data in bytes                                      |
+| calldatasize            |      | size of calldata in bytes                                       |
 +-------------------------+------+-----------------------------------------------------------------+
 | calldatacopy(t, f, s)   | `-`  | copy s bytes from calldata at position f to mem at position t   |
 +-------------------------+------+-----------------------------------------------------------------+
@@ -520,14 +522,14 @@ The opcodes ``pushi`` and ``jumpdest`` cannot be used directly.
 | create(v, p, s)         |      | create new contract with code mem[p..(p+s)) and send v wei      |
 |                         |      | and return the new address                                      |
 +-------------------------+------+-----------------------------------------------------------------+
-| call(g, a, v, in,       |      | call contract at address a with input mem[in..(in+insize)]      |
+| call(g, a, v, in,       |      | call contract at address a with input mem[in..(in+insize))      |
 | insize, out, outsize)   |      | providing g gas and v wei and output area                       |
-|                         |      | mem[out..(out+outsize)] returting 1 on error (out of gas)       |
+|                         |      | mem[out..(out+outsize)) returning 1 on error (out of gas)       |
 +-------------------------+------+-----------------------------------------------------------------+
-| callcode(g, a, v, in,   |      | identical to call but only use the code from a and stay         |
+| callcode(g, a, v, in,   |      | identical to `call` but only use the code from a and stay       |
 | insize, out, outsize)   |      | in the context of the current contract otherwise                |
 +-------------------------+------+-----------------------------------------------------------------+
-| delegatecall(g, a, in,  |      | identical to callcode but also keep ``caller``                  |
+| delegatecall(g, a, in,  |      | identical to `callcode` but also keep ``caller``                |
 | insize, out, outsize)   |      | and ``callvalue``                                               |
 +-------------------------+------+-----------------------------------------------------------------+
 | return(p, s)            | `*`  | end execution, return data mem[p..(p+s))                        |

docs/installing-solidity.rst

@@ -73,7 +73,7 @@ to compile Solidity on Ubuntu 14.04 (Trusty Tahr).
 
     sudo apt-get -y install build-essential git cmake libgmp-dev libboost-all-dev \
         libjsoncpp-dev
-    
+
     sudo add-apt-repository -y ppa:ethereum/ethereum
     sudo add-apt-repository -y ppa:ethereum/ethereum-dev
     sudo apt-get -y update
@@ -94,7 +94,7 @@ installed either by adding the Ethereum PPA (Option 1) or by backporting
 
     sudo apt-get -y install build-essential git cmake libgmp-dev libboost-all-dev \
         libjsoncpp-dev
-    
+
     # (Option 1) For those willing to add the Ethereum PPA:
     sudo add-apt-repository -y ppa:ethereum/ethereum
     sudo add-apt-repository -y ppa:ethereum/ethereum-dev

docs/introduction-to-smart-contracts.rst

@@ -95,7 +95,7 @@ registering with username and password - all you need is an Ethereum keypair.
 This contract introduces some new concepts, let us go through them one by one.
 
 The line ``address public minter;`` declares a state variable of type address
-that is publicly accessible. The ``address`` type is a 160 bit value
+that is publicly accessible. The ``address`` type is a 160-bit value
 that does not allow any arithmetic operations. It is suitable for
 storing addresses of contracts or keypairs belonging to external
 persons. The keyword ``public`` automatically generates a function that
@@ -220,7 +220,7 @@ only the person holding the keys to the account can transfer money from it.
 Blocks
 ======
 
-One major obstacle to overcome is what in bitcoin terms is called "double-spend attack":
+One major obstacle to overcome is what, in Bitcoin terms, is called "double-spend attack":
 What happens if two transactions exist in the network that both want to empty an account,
 a so-called conflict?
 
@@ -236,7 +236,7 @@ Ethereum this is roughly every 17 seconds.
 
 As part of the "order selection mechanism" (which is called "mining") it may happen that
 blocks are reverted from time to time, but only at the "tip" of the chain. The more
-blocks are reverted the less likely it is. So it might be that your transactions
+blocks that are added on top, the less likely it is. So it might be that your transactions
 are reverted and even removed from the blockchain, but the longer you wait, the less
 likely it will be.
 
@@ -277,7 +277,7 @@ of transactions sent from that address, the so-called "nonce").
 Apart from the fact whether an account stores code or not,
 the EVM treats the two types equally, though.
 
-Every account has a persistent key-value store mapping 256 bit words to 256 bit
+Every account has a persistent key-value store mapping 256-bit words to 256-bit
 words called **storage**.
 
 Furthermore, every account has a **balance** in
@@ -300,7 +300,7 @@ If the target account is the zero-account (the account with the
 address ``0``), the transaction creates a **new contract**.
 As already mentioned, the address of that contract is not
 the zero address but an address derived from the sender and
-its number of transaction sent (the "nonce"). The payload
+its number of transactions sent (the "nonce"). The payload
 of such a contract creation transaction is taken to be
 EVM bytecode and executed. The output of this execution is
 permanently stored as the code of the contract.
@@ -332,7 +332,7 @@ Storage, Memory and the Stack
 =============================
 
 Each account has a persistent memory area which is called **storage**.
-Storage is a key-value store that maps 256 bit words to 256 bit words.
+Storage is a key-value store that maps 256-bit words to 256-bit words.
 It is not possible to enumerate storage from within a contract
 and it is comparatively costly to read and even more so, to modify
 storage. A contract can neither read nor write to any storage apart
@@ -340,7 +340,7 @@ from its own.
 
 The second memory area is called **memory**, of which a contract obtains
 a freshly cleared instance for each message call. Memory can be
-addressed at byte level, but read and written to in 32 byte (256 bit)
+addressed at byte level, but read and written to in 32 byte (256-bit)
 chunks. Memory is more costly the larger it grows (it scales
 quadratically).
 
@@ -364,7 +364,7 @@ Instruction Set
 
 The instruction set of the EVM is kept minimal in order to avoid
 incorrect implementations which could cause consensus problems.
-All instructions operate on the basic data type, 256 bit words.
+All instructions operate on the basic data type, 256-bit words.
 The usual arithmetic, bit, logical and comparison operations are present.
 Conditional and unconditional jumps are possible. Furthermore,
 contracts can access relevant properties of the current block

docs/layout-of-source-files.rst

@@ -61,7 +61,7 @@ It depends on the compiler (see below) how to actually resolve the paths.
 In general, the directory hierarchy does not need to strictly map onto your local
 filesystem, it can also map to resources discovered via e.g. ipfs, http or git.
 
-Use in actual Compilers
+Use in Actual Compilers
 -----------------------
 
 When the compiler is invoked, it is not only possible to specify how to
@@ -171,9 +171,9 @@ for the two input parameters and two returned values.
       * @return s The calculated surface.
       * @return p The calculated perimeter.
       */
-     function rectangle(uint w, uint h) returns (uint s, uint p){
+     function rectangle(uint w, uint h) returns (uint s, uint p) {
-         s = w*h;
+         s = w * h;
-         p = 2*(w+h);
+         p = 2 * (w + h);
      }
  }
 

docs/miscellaneous.rst

@@ -66,7 +66,7 @@ Calling ``select(false, x)`` will compute ``x * x`` and ``select(true, x)`` will
 .. index:: optimizer, common subexpression elimination, constant propagation
 
 *************************
-Internals - the Optimizer
+Internals - The Optimizer
 *************************
 
 The Solidity optimizer operates on assembly, so it can be and also is used by other languages. It splits the sequence of instructions into basic blocks at JUMPs and JUMPDESTs. Inside these blocks, the instructions are analysed and every modification to the stack, to memory or storage is recorded as an expression which consists of an instruction and a list of arguments which are essentially pointers to other expressions. The main idea is now to find expressions that are always equal (on every input) and combine them into an expression class. The optimizer first tries to find each new expression in a list of already known expressions. If this does not work, the expression is simplified according to rules like ``constant + constant = sum_of_constants`` or ``X * 1 = X``. Since this is done recursively, we can also apply the latter rule if the second factor is a more complex expression where we know that it will always evaluate to one. Modifications to storage and memory locations have to erase knowledge about storage and memory locations which are not known to be different: If we first write to location x and then to location y and both are input variables, the second could overwrite the first, so we actually do not know what is stored at x after we wrote to y. On the other hand, if a simplification of the expression x - y evaluates to a non-zero constant, we know that we can keep our knowledge about what is stored at x.

docs/security-considerations.rst

@@ -147,7 +147,7 @@ Never use tx.origin for authorization. Let's say you have a wallet contract like
 
 ::
 
-    contract TxUserWallet {  
+    contract TxUserWallet {
         address owner;
 
         function TxUserWallet() {
@@ -164,7 +164,7 @@ Now someone tricks you into sending ether to the address of this attack wallet:
 
 ::
 
-    contract TxAttackWallet {  
+    contract TxAttackWallet {
         address owner;
 
         function TxAttackWallet() {