Fri Jul 17 15:04:31 CEST 2009
Packet Types + Macros
Let's see if this can be fixed. What about replacing pf_header.type
with a pointer to an object that can produce a pf_symbol_t type
Actually, this can be gotten from pf_header.theclass
So, let's simply remove .type and .desc and provide accessors for
Ok, this is a deep cut.. Might also need to do some of the macro
refactoring while I'm at it. I see last time I already replaced the
"return" based exception handling by a "longjmp" based one, so most of
the type checkers can actually be abstracted as functions.
Maybe it is possible to limit all macros to "implicit context" macros
that reference the vm struct?
These kinds are ok:
- simple renames: these can be left as-is, because they don't
increase the complexity of the code.
- "context" macros that implicitly bind an operation to a lexical
parameter (i.e. the vm). these are reasonably predictable and
when expanded don't raise complexity either.
Macros that perform composition that can also be performed by inline
functions should be eliminated. (statement sequencing, expression
nesting, struct dereferencing).
The PF_STACK_CHECK macros raise errors so they only make sense in a vm
context. however, this is I believe abused in a lot of places to do
"local" stack checks.
Ok, it's simpler to use packet_t.type as the name for the class: this
keeps most code that performs such checks intact, replacing the PF_XXX
by class instances.