PHP FFI's ioctl returns success on Apple Silicon while doing nothing at all

A developer building pseudo-terminal support for PHP found that an FFI-bound `ioctl()` call to set a terminal window size returns 0 on arm64 macOS while leaving the geometry as garbage, and spent an hour on it because nothing in the call reports failure ^[1][9]. The same declaration works on Linux x86-64 ^[17], which means a Linux-only CI matrix will green-light terminal control code that is broken on every Apple Silicon machine the team develops on ^[22].

The gap being closed is real. PHP's `proc_open()` already accepts `['pty']` descriptors and hands back a genuine `/dev/ttysNNN` on macOS ^[2], but there is no `ioctl()` in the standard library, so no `TIOCSWINSZ` and no `SIGWINCH` ^[3]. Full-screen programs render at whatever size they guessed at startup and never learn the window changed ^[4]. According to the writeup, that single missing call is why PHP projects that need to drive a terminal end up shipping a Node sidecar for `node-pty` ^[5].

The binding looked correct. Asking for 30 rows by 120 columns, the child process reported `/dev/ttys018` and a size of `0 2046` ^[7]. The author notes 2046 is not a truncation of 120, not a byte swap, and not a field-order mistake ^[8]. `ioctl()` returned 0 with no errno and no exception ^[9].

The isolation is the useful part. `openpty()` accepts a `struct winsize *` as its fifth argument and is not variadic ^[10], which separates a bad struct layout from a bad call. On PHP 8.5.8, Darwin, arm64 ^[12], setting the size through `openpty()` produced 30 by 120 ^[13]; `ioctl()` declared with fixed arity produced 0 by 2046 ^[14]; `ioctl()` declared variadic produced 30 by 120 ^[15]. All three returned 0 ^[16], so the return value carries no information. Ground truth came from `stty size` in a child attached to the pty, deliberately not `TIOCGWINSZ`, because reading the value back would travel through the same suspect call ^[11].

The mechanism is an ABI divergence, not a PHP bug. `ioctl` is variadic in C ^[18], yet most PHP FFI snippets in circulation declare a fixed `void *arg` third parameter ^[19]. On Linux x86-64 the variadic and non-variadic conventions agree for integers and pointers, so the value lands where the callee looks ^[17]. Apple's arm64 ABI diverges from AAPCS64: fixed arguments still travel in registers, but every variadic argument is passed on the stack ^[20]. Declared non-variadic, libffi builds a non-variadic frame and puts the pointer in x2, while the real `ioctl` reads the stack, treats whatever is there as a `struct winsize *`, and copies eight bytes ^[21]. If that address is unmapped you get EFAULT and a signal something is wrong; if it is readable, which is common, the call succeeds and writes nonsense ^[6]. The fix is declaring the ellipsis, after which PHP's parser and `ffi_prep_cif_var()` do the right thing ^[25].

This is not confined to PHP or to `ioctl`. Chez Scheme hit the same wall on arm64 macOS in issue #745, and any FFI layered over libffi can reproduce it ^[23]. Because the defect is in how variadic frames are built, any binding to a symbol whose C prototype ends in `...` but is declared with fixed arity is suspect on Apple Silicon ^[24].

Two things to check. First, whether your FFI declarations match libc prototypes exactly for variadic symbols, rather than the shape that happens to compile. Second, whether your test oracle is the return code or an out-of-band observation; here only the second caught it ^[16][11].