Preparing release v2.2 - #440
Merged
Merged
Conversation
Fixing when nightly version string is applied
Fix array bound errors when compiled with gcc13
…-temporary-values Fixing error with NULL comparisons and unnamed temporary values
- fdhookentry.c: replace broken multi-branch pipe read logic with a dedicated pipe path placed before the generic Read() call. Blocking mode: WaitForChar(50ms) retry loop until Read() >= 0. Non-blocking mode: single Read(); result < 0 checks other side — returns EAGAIN if write-end still open, EOF (0) if it is closed. This fixes the case where a non-blocking read on a pipe whose write-end was already closed wrongly returned EAGAIN instead of 0. - pipe2.c: set FDF_CLOEXEC on both ends (read and write) when O_CLOEXEC is passed, matching POSIX semantics. Also add __change_fd_user_data cross-reference (same as pipe.c) so the write path can correctly detect EPIPE. - test_programs/pipe/pipe_posix_test.c: new comprehensive POSIX pipe test covering 12 cases (basic rw, EOF, EAGAIN, non-blocking EOF, large data, EPIPE, blocking wait, O_CLOEXEC, producer/consumer).
pthread_getattr_np() returned a copy of the creation-time attributes,
whose stackaddr is normally NULL (and stacksize 0 when the default
size was used). The documented purpose of this Linux extension is the
opposite: report the thread''s ACTUAL stack so callers can derive live
stack bounds via pthread_attr_getstack() -- runtimes use this for
stack-overflow detection and GC stack scanning.
With the previous behaviour a caller computing
pthread_getattr_np(pthread_self(), &attr);
pthread_attr_getstack(&attr, &addr, &size);
stack_top = (char *)addr + size;
ended up with bounds unrelated to the real stack. (Found porting
OpenJDK 17 to AmigaOS 4: HotSpot sized its interpreter stack from
these bounds and computed a ~1.6 GB allocation.)
Fill in the live values from the exec Task structure, which always
knows the real stack: tc_SPLower / tc_SPUpper.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Using my fork of the upgraded discord notification action
Update github checkout action
Update action gh release
Update github action update-tag
* Make wmem allocator process-global singleton * Fixed a race condition in pthread_create when many thread were created
- fdopen/fopen: replace FLAG_IS_SET(open_mode, O_RDONLY) with O_ACCMODE mask comparison. FLAG_IS_SET with O_RDONLY=0 always returns true, causing IOBF_READ to be set on write-only streams. - fcntl F_GETFL: include O_RDONLY/O_WRONLY/O_RDWR and O_APPEND bits in the returned flags. Previously F_GETFL only returned O_NONBLOCK/ O_ASYNC/O_PATH, breaking the BFD-style 'fdflags & O_ACCMODE' switch. - fread: move cantread() check before the fast path. The fast path bypassed cantread when the buffer was already allocated, allowing reads on write-only streams to silently succeed. - fwrite: add cantwrite() check before the fast path, symmetric with the fread fix. - test_programs/unistd/fdopen_flags.c: new test covering all fdopen mode strings and the fcntl(F_GETFL)+O_ACCMODE pattern used by BFD.
vec_strcpy guarded its speculative source loads against crossing a 4K
page using the DESTINATION pointer, but the lvx loads come from the
SOURCE. When the source string ends near a page boundary while the
destination is mid-page, the dest-based counter is too large and the
loop keeps loading source vectors into the next (possibly unmapped)
page, causing a DSI crash on AltiVec CPUs (G4 / MPC744x/745x).
Guard from the QW-aligned source instead (lvx loads use addr & ~15), so
the loop stops at the source's page boundary, finds the NUL in the last
in-page vector, and finishes the tail by bytes. AltiVec acceleration is
preserved.
Adds test_programs/memory/{altivec_guard,memcpy_guard}.c -- guard-page
over-read/over-write tests for the AltiVec string/mem routines. Verified
under QEMU emulating an MPC 7447/7457 (G4, AltiVec): altivec_guard goes
from a DSI crash at strcpy len=16 to PASS across bcopy/memcmp/strcpy/
bzero x len 1..1024.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…rce() calls in malloc (#439) - Add __clib4_resource field to struct _clib4 for caching the global resource pointer - Initialize cache once in stdlib_memory_init instead of calling OpenResource() on every allocation - Update __get_wmem_allocator, __memory_lock, and __memory_unlock to use cached pointer - Eliminates 3 OpenResource() calls per malloc/free (hot path optimization) - Maintains global allocator semantics and thread-safety through shared resource semaphore
walkero-gr
requested review from
3246251196,
afxgroup,
elfpipe,
josefwegner,
kas1e and
migthymax
and removed request for
afxgroup
July 2, 2026 08:13
afxgroup
approved these changes
Jul 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.