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().
When building without this module MZInit() does not get called and
MZAttachHintPlanes() does not guard against that situation.
To allow unused code to be pruned from final binary, better to remove
the cross module hook breaking the dependency.
API docs indicate the original usage seems ok.
Calling Tcl_GetIndexFromObj() is allowed with a refcount == 0.
But in actual usage it leaks the Tcl_NewStringObj() memory across the
Tcl_EvalObjv() call like the object accounting system doesn't work on
that anymore (because the use of Tcl_EvalObjv() disrupted things).
Looking at the code nearby it increments refs (for all recently created
objs) and decrements around Tcl_EvalEx() for the actual data the 'eval'
needs pinned and is working on.
If we just repeat this same pattern but with 'objv0' the memory leak is
gone. The decrement must wake it up / make it remember what to do.
So this required covering all the exit paths to decrement as well.
Darryl L. Miles
R. Timothy Edwards