int spcnAP() follows K&R param ordering
int spcnAPHier() follows K&R param ordering
TODO mergeAttr() sharing references (does this setup a future potential
use-after-free concern?)
Not a serious attempt to make these work but they appear to compile
so this helps CI to cover as much code as possible.
ext2sim_main standalone does not link (probably due to unclean cross
module dependencies that now exist due to libutil.a being a heap where
anything with no modular home ends up)
commit 86b5d591d from 20241004 by me, modified return type of
GrTextSize API in the graphics from 'void' to 'int' to convey
and error scenario to indicate when 'r' was not filled in for
the caller, but this is a multi graphics driver API interface
so requires all downstream graphics engines to also support
the return type change.
This API can error and indicates when 'Rect *r' was
successfully updated.
The man page end(3) changed as well over time to support the new definition.
This was revised from 2.41+ to 2.29+ as it seems top relate to a mix of
Kernel / Glibc / Compiler and the new defintion probably works on any
older system.
When global <sys/mman.h> was removed from tile.h it also removed
<unistd.h> nearby. This exposes the lack of <unistd.h> being
included where needed using APIs like close()/read()/unlink()/isatty()
the WASM build seems to show this as the header file set is structured
differently.
tile.h is included by a large part of the project, but the definitions
in sys/mman.h are only needed by the implementation code inside tile.c
so this reduces project wide include dependencies.
Removal of unnecessary function call indirection into TileStoreFree()
since TiFree() is has multiple implementation already and we can
customize TiFree() directly as required.
Move the function definitions into the tile.h to they are visible to
compiler during code generation to consider inline potential.
This has made global 'Tile *TileStoreFreeList' more visible.
The comment indicates the expectation that TiFree() is deferred-by-one,
which would be true if freeMalloc() was used but since the custom mmap()
allocator technically this is not true.
The TiFree() allocator is single-threaded and separate from libc so the
assumption is still kind of true but for different reasons
(single-threaded).
But since it doesn't really cost anything (other than a few lines of
code a human needs to read) the compiler would be expected to perform a
load (which it was going to do anyway) into a caller-saves register over
the function call.
Most of the other function state is invalidated anyway due to the heavy
linked-list navigation and low number of local variables, I would not
think there is much register allocation pressure.
TODO this code can be tested by confirming zero allocations are active
and by invalidating (poison) all fields inside TiFree().
Torleif Skår
Darryl L. Miles
R. Timothy Edwards