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.
overhead of the sexp tag and should thus fit in any aligned
block on 64bit architectures. this also removes a lot of
ugly casts, making the code more readable.
type definitions and for the sexp type enum. They shouldn't conflict,
since the enum is in the enum namespace, but apparently they do in
mscv. Chaging the defs to sexp_type_specs.
