Other than its blocking of access to certain files, it really wasn't
that useful compared to the functions in qfs, and pointless with access
to qfs anyway.
This far better reflects the actual meaning. It is very likely that
ty_none is a holdover from long before there was full type encoding and
it meant that the union in qfcc's type_t had no data. This is still
true for basic types, but only if not a function, field or pointer type.
If the type was function, field or pointer, it was not true, so it was
misnamed pretty much from the start.
Only as scalars, I still need to think about what to do for vectors and
quaternions due to param size issues. Also, doubles are not yet
guaranteed to be correctly aligned.
Empty structs are now (correctly) invalid. The hack of using an empty
struct to represent a handle returned from a builtin has been unnecessary
since opaque structs were implemented: now a pointer to an opaque struct
can be used. This is mostly safe as handles are aways negative and thus
attempting to dereference such a pointer should result in a VM error. It
will be even safer once const is implemented and the pointers can be made
constant (eg, typedef struct handle * const handle;)
As class objects don't have retain counts (they're usually static, even!!),
allowing the instance implementations of retain, release, and autorelease
attempt to modify the non-existant retainCount would be a recipe for severe
headaches. We also don't want the retainCount returning "random" values.
Going by "standard" Objective-C, retainCount really doesn't belong in
Object itself. The way GNUStep does it is to stash retainCount in memory
just below the object by allocating extra bytes for the count and returning
a pointer just beyond those extra bytes. Now Ruamoko does the same. This
fixes the inconsistencies in structure layouts for Protocol and class
structs between qfcc generated (internal) structs and user visible structs.
The api hides all the gory details of message buffer setup and usage
(particularly the differences between writing and reading). Most
importantly, the api provides a safe way to read and write binary data
(always little endian).
The special token __INFINITY__, like __FILE__ and friends, will expand to
a floating-point expression containing a value the C compiler considers
infinite. Obviously, this assumes that the system has relatively modern
float hardware -- but if it doesn't, having Ruamoko be able to represent
float infinity is the least of your problems. :)
Use the resource map code for handle management (much safer).
Add support for the enter callback (function or method).
Unfortunately, it still doesn't work due to poor design of the inputline
user data.
