operator new — CfcGuidanceSpeedTableFuture::operator new

Part of Firmware Reversing.

• File offset: 0x6420cc (VA 0xf6ecfdc0)
• Status: 🟡* Partially traced — a clean prologue (0x20-byte frame), small (88 bytes to the anomaly), real logic confirmed. Note: this page exists to close out the "4 clean gold-standard functions" list on Firmware Reversing — that note historically described the 4th as "a CfcGuidanceSpeedTableFuture destructor," but re-checked directly this session: the real destructor (__vd__27CfcGuidanceSpeedTableFuturePv) is NOT a clean prologue match (lands mid-body); operator new for the same class is the one that's actually clean — the list entry was corrected to point at this function instead.
• Full mangled name: __nw__27CfcGuidanceSpeedTableFutureUi

Real, confirmed behavior

Calls a real allocator (indirect, through a vtable-style pointer, not independently named), then initializes a node as its own circular self-reference — stw r9,0(r9) / stw r9,4(r9), the standard "empty list sentinel" pattern (a node whose forward/backward pointers both point to itself) — consistent with constructing a Future object that embeds itself into a pending-futures linked list, initially empty. Ends in what is most likely another (10th) instance of the central "no locally-visible blr" anomaly documented on Firmware Reversing, though here the usual explicit frame-pop (addi r1,r1,N) wasn't clearly visible before the anomaly data — not resolved further.

Net read

A small, real, plausible operator new for a "guidance speed table" future/promise-style object, initializing it as an empty linked-list node before (presumably) the caller fills in the actual guidance-speed data. Confirms the general C++ "Future" pattern (asynchronous pending-result objects) already seen elsewhere on this wiki (CfcMediaVoidFuture, CfcGuidanceGuidanceStatusSetFuture, CfcCtrlDestroyCompleteFuture) extends to guidance speed-table data too.