The htab functions find_str and add_str have been renamed to include _ref in the places they previously noted _str. These are intended to manage an htab containing references to any data; string or not. The htab_find function has been divided up. htab_find_core now handles actually finding the correct node. htab_find and htab_find_ref are just outward facing functions for retrieving a specific kind of data from the node, depending on what the htab is used for.
This is the last remaining instance of this assumption.
The htab_structure has been modified in two ways, which should not break compatability with any of its uses. It includes a void pointer, which is in this commit used to point to a string for defines, and will in the future be used to point to the address space for words, bytes, and double words. It now includes a function htab_add_str specifically for storing strings. It calls htab_add so as not to be redundant, but makes the node's value their index for the lexer to fetch using htab_find, and assigns their void pointer. The lexer will now use htab_find on all tokens to see if they are a define string, and if so, substitute them with the appropriate token. The defines htab is destroyed after lexing, because that memory is done.
Before allocating space for a token, the lexer will first check to see if that token is a defined name. If it is, it will allocate space for the defined string instead. A test file is included in programs/tinyvm/preprocessor to demonstrate the behavior. When functioning, the program will print the fibonacci sequence.
The tvm_tree structure should optionally be able to keep track of values associated with the strings by which its nodes are sorted. In the case of defines, this is the replacement string. In the case of variables, this will be a pointer to the variable's location in memory. Searching should return the value, or NULL. To opt out of storing a value, pass NULL and 0 as the val and len arguments.
The tvm_tree structure is a binary search tree. It will be used to hold preprocessor defines, and variable names for when defining bytes, words, and double words is implemented. Each node structure and its own string are stored contiguously (in that order) so the free's are easier to keep track of, and memory doesn't need to be a concern when adding a string to the tree.
If the entire parenthesized division expression is cast to float, as it was prior to this commit, C performs truncating integer division before converting to float, which always leads to a result of zero. `git-blame' traces the bug to commit d5ed7e7, which added the faulty parentheses as a matter of style. No parentheses are necessary, since increments have higher precedence than type-casts, type-casts have higher precedence than division, and division has higher precedence than comparison. The operations will execute in the desired order.