This commit is the substantive portion of the Waif implementation.
The combination of this commit with its parent
(add back waif-related cvs log comments)
is intended to match either of the differences:
codepoint/unicode (51761cdc98)
..codepoint/unicode-waif (8f892adbf7b6a5973c3268942087584eb01242f1)
codepoint/unicode-xml (67aa153f76bcdbd9917bdf57fd380d9e7ffb419e)
..codepoint/unicode-waif-xml( c3d6fa5e58e358a0a75662a6ddaaecab4d39f306)
(these are both essentially the same) except for those files for which
the only differences are in the CVS log entries.
This version is purposefully broken (in order that the differences
line up as well as possible), notably in execute.c
(OP_INDEXSET,OP_REF,OP_CALL_VERB).
Time to impose some discipline on #include header ordering:
(1) We need to be absolutely certain everybody is seeing
the SAME #define settings from config.h and options.h
(so many of the my_foo.h depend on config.h settings
and yet config.h was being listed later. how did this happen?)
(2) It REALLY helps for documentation and code comprehension
to have .c files clearly point to the .h files that
export their interfaces (usually it's the like-named .h
but sometimes it is not and this can be confusing to
the newbie maintainer)
So... new rules:
For .h files:
config.h if referenced, goes FIRST.
options.h if referenced, goes SECOND.
For .c files the ordering of #includes shall be:
(1) The .h file(s) defining the exported interfaces
that this .c file is implementing
(typically this will be just one file, foo.h
if this is foo.c, but exceptions exist)
(2) config.h, then options.h, in a stanza by themselves
if referenced and not already included by (1)
For both .c and .h files we then have two more stanzas:
(3) system headers,
including the "my-foo.h" corrective headers.
(4) own headers, other than the ones that go in (1)
Except for special cases like net_proto.c and net_mplex.c
where the whole purpose of the file is to BE an #include festival,
there should be no further #includes after the initial block.
All includes should appear at the top of the file where we can see them.
... ok, I'm done.
store strlen with strings. This is basically free, since most string
allocations are rounded up by malloc anyway. This saves lots of cycles
computing strlen. (The change is originally from jitmoo, where I wanted
inline range checks for string ops).
