Replacing sexp_make_integer, sexp_integerp, etc. with sexp_make_fixnum,
sexp_fixnump, etc. Defining the old names as variants handling either
fixnums or bignums, or just as aliases for the new terms when compiled
without bignum support. sexp_make_integer needs to take a context now
in case it generates a bignum.
Adding sexp_gc_var1..6 and corresponding _preserve/release1..6
referring to fixed preservation variable names, to substantially
reduce the boilerplate on C functions which produce temporary sexp
values. The fixed variable names are safe because we never nest
them within the same C function. The original macros are still
available for manual naming, block local variables and cases of
more than 6 gc vars.
Consider combining var+preserve into a single macro, since splitting
them is rare.
Using <u.h> and <libc.h> for plan9, no need for separate .i file
construction. Also mkfile now simplified and using /sys/src/cmd/mkone
(thanks to Charles Forsyth).
Notably no longer converting from function pointers <-> void*.
Remaining --pedantic warnings:
* ISO C90 does not support 'long long'
* ISO C90 does not support the 'z' printf length modifier
* ISO C90 does not support flexible array members
* ISO C90 forbids mixed declarations and code
* ISO C90 forbids specifying subobject to initialize
* anonymous variadic macros were introduced in C99
* invalid use of structure with flexible array member
The first one is only used when optional bignums are enabled,
and I have no intention of supporting bignums on systems w/o
long long (although it's not guaranteed two words fit in a
long long - I need to fix this).
The 'z' modifier is necessary for long types (you'd get
warnings the other way without it).
The next 4 are intentional - they make the code cleaner,
and all of these extensions are supported by Plan 9.
The last one is tricky. I think it refers to the fact
that not only am I using flexible array members, but I'm
using them as non-final alternates in a union. I'll have
to double check the semantics of this.
can disable with USE_BIGNUMS=0 - the interactions between this and
USE_FLONUMS are messy, so they will likely be merged into a single
option in the near future (i.e. you either have only fixnums, or a
full range of numeric types).
adding rationals based on this would be easy and is a likely future
feature. adding native support for complex numbers is unlikely.
