.. the previous arrangement lead to compiler diagnostics when
building with 'scan-build make':
libtvm/tvm_htab.c:113:3: warning: Value stored to 'node' is never read
node = node->next;
^ ~~~~~~~~~~
This commit refactors the project using a single, consistent coding
style, derived from the Linux Kernel Coding Style, available here:
https://www.kernel.org/doc/Documentation/CodingStyle
This includes, but is not limited to:
* Removal of typedefs, especially for structs
* Limiting lines to a reasonable length, 80 characters, mostly
* K&R style braces
* Removal of CamelCase
If htab_add_core added a node that happened to push the htab past its load
factor, it would return a pointer to where the added node was *before* the
rehash. Now it does not do this.
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.
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.
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 d5ed7e75d9, 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.
