Here is a small AArch64 bug:

bad_wrapper:
 bl helper
 ret

It looks plausible if the mental model came from x86. Call a helper. Return to the caller. But AArch64 bl does not push a return address onto the stack. It writes the return address into the link register, x30. If bad_wrapper entered with its caller’s return address in x30, then bl helper overwrote it. The later ret no longer has the original link-register state.

A non-leaf wrapper usually has to preserve what it will need after the nested call:

good_wrapper:
 stp x29, x30, [sp, #-16]!
 mov x29, sp
 bl helper
 ldp x29, x30, [sp], #16
 ret

That is the claim: ARM64 is not x64 with a larger register file. The instruction set gives you registers. The ABI tells you which registers are part of the call packet, which ones are reserved, how the stack behaves, where the return address lives, and which platform rules apply.

AAPCS64 gives a clean first table. x0 through x7 are parameter/result registers. v0 through v7 carry floating-point and SIMD arguments. x30 is the link register. x29 is the frame pointer. x8 can be the indirect result location register.

That table is useful. It is not the whole ABI.

The sharp example is x18. Architecturally, it is a general-purpose register. ABI-wise, it has a passport problem. AAPCS64 defines it as platform-specific and warns portable hand-written assembly to avoid it. Windows ARM64 reserves x18 as a platform register. Code that casually uses it as scratch may work in one environment and violate the platform contract in another.

Stack rules have the same shape. Alignment, red zones, frame-pointer expectations, and unwind metadata are platform ABI properties, not facts you get from the words “ARM64.” ARM64EC makes the point even harder: it runs on ARM64 hardware, but follows x64-oriented software conventions for mixed ARM64/x64 interoperability on Windows.

The boundary is evidence. A register-file fact is not automatically an ABI fact. A base ABI fact is not automatically a platform fact. A platform ABI fact is not universal hardware behavior.

Ask which ARM64 ABI you are in before deciding what a register means.

Read the full essay on lospino.so: ARM64 Is Not Just x64 With More Registers

Original essay published on lospino.so on 2026-06-05. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

C++ is not a superset of C.

That warning is still accurate, but it is less useful when stated without a language mode. The 2019 version of this post surveyed C constructs that do not work in C++. The 2026 update does not retire that advice. It makes the border more precise.

The question is no longer only “does valid C compile as C++?” Often it is: C17, C23, C++17, C++20, or C++23?

Designated initialization is the clean example. C++20 added designated initializers, but not the whole C feature. C designators can target array elements, nested members, and fields out of declaration order. The C++20 form is narrower: direct non-static data members, declaration order, and all-designated clauses. C-style array designators, nested designators, out-of-order designators, and mixed positional/designated clauses remain outside the portable C++ form.

The old empty-parameter-list trap moved too. In C17 and earlier, void f() did not mean the same thing C++ programmers normally expect. It did not provide a prototype saying “no parameters.” C23 changed that: void f() now behaves as though declared with void. So the compatibility answer depends on which C mode is in play.

The malloc row is still easy to misread. In C++, void* does not implicitly convert to an object pointer type. But the cast is not the interesting part. Lifetime is. C++20 repaired some implicit-lifetime cases around allocation, but allocation still does not call constructors, initialize values, or make non-implicit-lifetime types safe to use without construction.

Other checkpoint rows remain: discarding const, enum behavior including C23 changes, restrict, and flexible array members. Each row is less a trivia question than a reminder that source compatibility, ABI boundaries, object lifetime, and compiler mode are different obligations.

The practical rule is simple: when discussing C/C++ compatibility, label the language mode before drawing the conclusion. “Valid C” and “valid C++” are not precise enough anymore.

Read the full essay on lospino.so: C Constructs That Still Don’t Work in C++ - and a Few That Changed

Original essay published on lospino.so on 2026-05-20. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

This Rust declaration is not just convenient syntax:

unsafe extern "C" {
 fn five_ints(a: i32, b: i32, c: i32, d: i32, e: i32) -> i32;
}

It is a boundary claim.

The declaration says there is a function somewhere else. It says Rust should lower the call using the target’s C ABI rather than Rust’s own internal calling convention. It says the source-level types in the declaration match the binary packet the other side will decode. The compiler can generate the packet. It cannot prove the declaration is true.

That is the claim of the essay: modern software has not escaped ABI problems. It has moved them to sharper composition points: Rust FFI, Python native extensions, WebAssembly components, eBPF helpers, plugin APIs, and compatibility modes.

A boring C-shaped plugin table shows why this keeps happening:

struct plugin_api {
 int (*open)(void *ctx, const char *path);
 int (*read)(void *ctx, void *buf, unsigned long len);
 void (*close)(void *ctx);
};

This is not elegant in the way high-level language APIs are elegant. That is part of the point. The receiver is explicit. The context pointer is explicit. The function signatures are fixed. C++ object layout, exceptions, hidden receivers, and runtime-specific ownership semantics do not leak directly into the public contract. The boundary still has many ways to fail - integer widths, alignment, lifetime, allocator ownership, callback table layout - but fewer of them are invisible.

The boundary matters because independently built pieces do not share intent. They share a packet. In Rust FFI, the packet is a native call. In CPython’s Stable ABI, it is a versioned symbol and structure contract. In WebAssembly components, it is canonical lowering through core Wasm values and linear memory. In eBPF, it is a verifier-understood register convention.

Do not overread the design rule. A C-shaped boundary is not automatically safe. A stable runtime ABI does not repeal the platform ABI beneath it. A high-level declaration does not prove a binary fact.

The safer rule is narrower: when two independently built systems meet, specify the packet the other side can actually decode.

Read the full essay on lospino.so: The ABI Is the Boundary

Original essay published on lospino.so on 2026-06-09. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

A hand-written function, JIT stub, or trampoline can pass the easiest test: it returns to the caller with the right value.

That is not enough.

The claim in this essay is narrower and more useful: modern ABI correctness includes the failure path. A function frame has to be executable on the sunny path and explainable when an exception runtime, debugger, profiler, sanitizer, or crash reporter needs to reconstruct the caller. Returning correctly proves the epilogue worked. It does not prove the frame can be unwound.

The concrete artifact is unwind metadata. On Windows x64, a non-leaf function that allocates stack or calls another function is not fully described by its code bytes alone. The system also needs a function-table entry and unwind information: where the function starts and ends, how much stack it allocated, which nonvolatile registers were saved, and how to recover the caller’s state. On ELF-oriented toolchains, hand-written assembly often tells the same story through CFI directives:

.cfi_startproc
push rbp
.cfi_def_cfa_offset 16
.cfi_offset rbp, -16
mov rbp, rsp
.cfi_def_cfa_register rbp
call helper
pop rbp
.cfi_def_cfa rsp, 8
ret
.cfi_endproc

The exact encoding varies by platform. The mechanism does not: a live frame needs a machine-readable explanation.

The boundary is important. This is not a claim that every small leaf helper needs elaborate metadata, or that one Windows rule generalizes cleanly to every object format. Leaf-function shortcuts exist. Platform rules differ. The bug appears when the function evolves - adds a call, saves a nonvolatile register, allocates scratch space, or becomes a trampoline - and the frame description does not evolve with it.

That creates a boring failure mode, which is why it is common: the code works until observability enters the system.

That is the practical boundary: the call has to remain explainable to the machinery that arrives after the sunny path has already succeeded.

Read the full essay on lospino.so: It Works Until the Stack Walker Arrives

Original essay published on lospino.so on 2026-06-08. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

printf is not just another function call.

Its signature stops describing the interesting part:

int printf(const char *fmt, ...);

The fixed prefix says there is a format string. The ellipsis says the rest of the typed parameter list is missing. The caller may pass an int, a double, a pointer, a promoted char, a promoted float, or a sequence selected by another layer. The callee does not receive named source-level parameters for those trailing values. It receives ABI state and a va_list mechanism that must recover them later.

That is the claim: varargs are not merely flexible syntax. They are a function-call protocol with missing type information.

A small artifact shows the problem:

int call_printf_double(double x) {
 return printf("x=%f\n", x);
}

On System V AMD64, the format string goes in rdi, the double is in xmm0, and the caller sets al to indicate vector-register usage for a call that may reach a variadic callee. That AL marker is not visible in the C signature, but the variadic machinery depends on it.

Windows x64 solves a related problem differently. For a vararg or unprototyped call, a floating-point value must be duplicated into the corresponding general-purpose register as well as the floating-point register. In the printf(”x=%f\n”, x) shape, the wrapper can move the floating-point value into the right XMM lane and also copy its bits into the matching integer register.

Same source value. Different transport rules.

The format string does not replace the ABI. It tells printf what to request. It does not place the unnamed double in an XMM register, duplicate it into a general-purpose register, set AL, create a register-save area, or put overflow arguments on the stack in the expected location.

The boundary is FFI. A foreign-function bridge can often model a fixed signature:

void log_f64(const char *label, double value);

A variadic function asks it to model a family of call shapes. Each unnamed suffix can change register usage, stack usage, and ABI-specific metadata. The conservative rule is boring because it is correct: avoid exposing variadic C APIs across language boundaries when fixed wrappers are practical.

Read the full essay on lospino.so: Varargs: The Function Call With Missing Type Information

Original essay published on lospino.so on 2026-06-04. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

The most important field in a function call is often the one the source code did not spell.

A programmer may write:

struct Big make_big(long long seed);

The ABI may need a different shape:

make_big(result_storage, seed)

That is the claim: the source-level function signature is not the full call packet. It tells the programmer what expression is legal. It does not necessarily tell the binary where the return storage lives, how the callee receives an object pointer, which runtime context arrives first, or whether a thunk has adjusted the receiver before control reaches the final implementation.

The cleanest artifact is a large structure return. In one fixture, the source function returns a record by value:

struct SretRecord make_sret_record(unsigned long long seed,
 unsigned long long tag);

At the ABI layer, several platforms turn that return value into an incoming storage channel. On Windows x64, the caller-allocated return storage can arrive as the first argument, shifting the visible values right. On System V AMD64, MEMORY-class returns use caller-provided storage in RDI as if it were the first argument. On AArch64, the indirect result location has a dedicated role in x8, so the visible seed and tag can remain in x0 and x1.

Same source shape. Different hidden-field placement.

The pattern does not stop with structure returns. A C++ member function needs a receiver even when the object sits outside the parentheses:

counter.add(5);

The callee still needs something like:

Counter_add(object, 5)

JNI makes the runtime version explicit: native methods receive JNIEnv * first, then either the object or class, then the ordinary Java parameters.

The boundary is important. Hidden arguments are not hacks, and the source signature is not dishonest. It is faithful at its layer. The mistake is carrying that layer across a real ABI or FFI boundary and assuming the visible parameter list is the complete wire format.

The safer question is not only: what are the parameters?

It is: what are the ABI-visible fields?

Read the full essay on lospino.so: Hidden Arguments Are Everywhere

Original essay published on lospino.so on 2026-06-03. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

ABI rules are easier to remember when you watch the packet break.

Here is a deliberately malformed sketch:

; Windows-shaped setup, SysV-shaped callee
sub rsp, 40
mov dword ptr [rsp + 32], 5
mov ecx, 1
mov edx, 2
mov r8d, 3
mov r9d, 4
call five_ints

Every instruction is real. The call target can exist. The machine can execute the sequence. The packet is still wrong.

If the callee decodes the call under the System V AMD64 ABI, this is not a correct encoding of:

five_ints(1, 2, 3, 4, 5);

For this all-integer function, a SysV AMD64 callee expects edi = a, esi = b, edx = c, ecx = d, and r8d = e. The sketch above was built from a Windows x64 mental model: ecx, edx, r8d, r9d, then a stack slot after the home area. The callee is not obligated to share that belief.

The concrete technical artifact is the wrong-register-schema bug. It does not require undefined source code or an invalid instruction. It requires a caller and callee that disagree about how local state has been serialized. A tracer may record the wrong argument. A hook may forward the wrong field. An FFI bridge may appear to work for one call shape and fail when the destination ABI changes.

The claim is broader than register tables: ABI bugs are malformed local serialization. The source call can be plausible while the binary packet is wrong. Hidden result storage, hidden receivers, stack home areas, varargs recovery state, and platform-specific preservation rules are all fields in that packet.

The boundary matters. The bug zoo is not a standards document, and a compiler listing is not the law. The disciplined rule is: ABI document as authority, generated assembly as receipt. A receipt can show what one compiler emitted for one target and one source shape. It cannot prove every compiler emits that sequence, every malformed call crashes, or every symptom looks the same.

The useful habit is adversarial but restrained: source belief, ABI field, broken packet, narrow symptom claim, evidence boundary.

Read the full essay on lospino.so: The Bugs That Make ABI Rules Memorable

Original essay published on lospino.so on 2026-06-02. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

A register name is not a meaning.

Start with a deliberately boring function:

int five_ints(int a, int b, int c, int d, int e);

And a deliberately boring call:

five_ints(1, 2, 3, 4, 5);

Nothing about the source is clever. Every argument is visible. The return value is a plain int. There is no hidden structure return, no C++ receiver, no varargs, no virtual dispatch, and no interesting object model problem. That is why the example is useful. If the generated call differs across targets, the difference is the ABI packet.

The concrete artifact is the ecx trap:

; Windows x64
mov ecx, 1 ; a

; System V AMD64 mov ecx, 4 ; d

The same physical register carries different semantic fields under different ABIs. On Windows x64, integer arguments in the leftmost four positions use RCX, RDX, R8, and R9; the fifth argument goes on the stack after the caller-provided home area. On System V AMD64, the integer register sequence begins RDI, RSI, RDX, RCX, R8, R9. On AArch64 Linux, this all-integer call maps cleanly to w0 through w4.

The claim is small but important: a source-level call does not carry a universal register schema. The ABI gives locations meaning. Without that schema, rcx is just a register.

This is where reverse-engineering, tracing, hooking, and FFI code go wrong. A tool that labels rcx as “argument 1” has already made a platform claim. That claim is correct in one context and wrong in another. The machine may still execute the instruction stream. The failure is not necessarily an illegal instruction or an immediate crash. It may be a valid instruction stream in the wrong language.

The boundary is also important. A compiler listing is a receipt, not the authority. Optimizers can inline, fold, tail-call, spill, or reshape a wrapper while still respecting the ABI at the real boundary. The ABI document defines the contract; the assembly gives you a microscope for one controlled source shape.

Read the full essay on lospino.so: Same Function, Three Realities

Original essay published on lospino.so on 2026-06-01. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

Subscribe now

A function signature tells you what a source-level call is allowed to look like. It does not tell you the whole binary protocol the caller and callee must speak.

Consider this ordinary-looking declaration:

struct Big make_big(long long seed);

At the source level, there is one visible argument and one return value. At the ABI boundary, that can become a different packet. If struct Big is not returned in registers, the caller may allocate result storage and pass a pointer to that storage into the callee. That pointer is not written in the source signature, but it is part of the call.

The concrete artifact is the hidden result-storage path. For a deliberately large return object, common 64-bit ABIs do not all encode the same source call the same way. On Windows x64, the result pointer is passed in RCX, and the visible seed shifts to RDX. On System V AMD64, the result pointer is passed in RDI, and seed shifts to RSI. On AAPCS64, the indirect result location uses x8, while the visible argument can remain in x0.

That distinction matters for JIT stubs, FFI bridges, hooks, hand-written trampolines, profilers, and any code that constructs or interprets a call below the source language. A bridge that sends only the visible arguments may build a packet the callee cannot decode. On Windows x64 or System V AMD64, the first visible value can land where the callee expects a writable result address. On AAPCS64, the visible arguments may look correct while x8 is stale or unset.

The boundary is narrow. This does not mean every source-level call literally performs a platform ABI ceremony at runtime. The compiler can inline, fold, specialize, or erase calls when both sides are under its control. The ABI matters when independently compiled code must meet.

The safer claim is this: the function signature is a programmer-facing projection. The ABI call is the machine-facing protocol.

Read the full essay on lospino.so: The Function Signature Is a Lie

Original essay published on lospino.so on 2026-05-29.

Abrade started from a small useful premise: generate patterned URLs, probe them, and record the candidates that appear to exist.

That premise is still useful. It is also too small if the crawler treats every kind of “success” as the same claim.

The 2026 refresh of Abrade, a C++23 command-line crawler, is mostly about separating those claims. The pressure point is simple: 2xx is transport evidence, not content truth. A server returning HTTP 200 may only prove that the request reached an HTTP application and received a successful response class. It does not prove that the response is the record being sought.

It can be an empty result, a placeholder, a login wall, a shell page, a default route, or a route that exists without containing the domain object.

That difference matters because “the request completed,” “the body contains evidence,” and “the run had operational problems” are not interchangeable. Abrade v0.3.0 makes that distinction explicit. It still generates candidate resource paths and performs concurrent HTTP requests. It still defaults to HEAD, and it can fetch bodies with GET. But the refreshed tool adds clearer boundaries around what is being measured: TLS with SNI for DNS host names, optional platform CA and DNS host verification with --verify, conservative redirects, dry-run generation, body-only output, body filters, and run summaries that account for filtered bodies, runtime errors, bytes written, and throughput.

One diagnostic sample in the canonical post exposed two common crawler mistakes. Without SNI, HTTPS failed before there was any meaningful application response. After SNI, many 200 responses still were not useful records. TLS success was one claim. Verified identity was another. Status-code success was another. Content evidence had to be checked separately.

The content-oriented pass is where the crawler stops pretending status success is enough. --contents writes body-only files. --require and --require-regex keep bodies containing required evidence. --reject and --reject-regex remove bodies containing absence, shell, or other non-record evidence.

Those strings are not universal predicates. They have to come from authorized knowledge of the application being tested. That is also the use boundary: authorized resource discovery, migration checks, and repeatable diagnostics against systems you own or are allowed to test.

Read the full essay on lospino.so:
Abrade After the Happy Path

Original essay published on lospino.so on 2026-07-09. This Substack dispatch is an adapted pointer to the canonical version, not a mirrored copy.

The old call model was small enough to fit in two instructions:

call target
ret

A call transferred control. A return transferred it back. If the arguments, stack, and return address were plausible enough, execution continued.

That model is now incomplete.

The claim of the essay is that calls and returns are no longer just conventions. On hardened platforms, parts of the call protocol may be checked by hardware, the kernel, the loader, compiler instrumentation, or the runtime. The call boundary can carry security state as well as value state.

The concrete artifact is a shadow stack. In an Intel CET shadow-stack model, a CALL records the return address on both the normal stack and a protected shadow stack. On RET, the processor compares the two. A mismatch is not just a bad return. It is a control-protection failure.

That changes what it means to preserve call state. A hand-written stub or trampoline may satisfy the old visible rule - put a plausible return address on the normal stack - and still violate the hardened rule: the normal return address and the shadow-stack return address must agree.

Other mechanisms check different edges. Branch Target Identification can require indirect branch targets to land on approved landing instructions. Pointer authentication can make a code pointer or return address more than an integer-shaped address. Windows Control Flow Guard can turn indirect-call validity into runtime metadata and checks. These mechanisms are not interchangeable, but they all pressure the same old assumption: a control transfer is not just an address.

The boundary is important. This is not a bypass guide, and it is not a claim that every modern CPU enforces every call. Feature availability, operating-system support, binary opt-in, compiler settings, and platform ABI choices all matter. The safer claim is narrower: modern platforms increasingly enforce pieces of the call and return protocol.

That matters for JITs, hooks, plugins, instrumentation, trampolines, and hand-written assembly. The old checklist asked whether the code preserved arguments, nonvolatile registers, stack alignment, and return behavior. The newer checklist also asks whether unwinders can explain the frame and whether the security machinery accepts the transfer.

A call is still a call. It just has more witnesses.

Read the full essay on lospino.so: Calls Are Now a Security Surface

Original essay published on lospino.so on 2026-06-10.