---
name: LLDB data formatter style — let lldb do the math
description: In tools/UEDataFormatter.py and similar lldb formatter code, use typed SBValues so lldb handles alignment/pointer-size/endianness, rather than doing raw byte math in Python.
type: feedback
originSessionId: 783fd7be-2cf8-4075-a708-2909c6cf000b
---
In `tools/UEDataFormatter.py` (and any other lldb data formatter code in this project): use typed SBValues to let lldb compute offsets, alignments, pointer sizes, and endianness. Do not do raw pointer arithmetic, byte-offset math, or architecture-assumption math in Python.

**Why:** Manual math assumes things about the target (pointer size, struct layout, endianness) that lldb already knows from debug info. Letting lldb do it via typed SBValue APIs — `GetChildMemberWithName`, `Dereference`, `CreateValueFromAddress(addr, type)`, `GetArrayType`, `GetTemplateArgumentType`, etc. — is portable, robust, and avoids subtle bugs when the target architecture changes.

**How to apply:** When writing or editing a summary/synth provider:
- Prefer `GetChildMemberWithName('X')` over computing a field's offset and doing `ReadMemory`.
- Prefer `CreateValueFromAddress(addr, sometype)` over raw reads followed by manual decoding.
- Use `GetArrayType(N)` / `GetTemplateArgumentType(i)` to derive element types rather than hardcoding sizes.
- Only drop to raw `process.ReadMemory` / pointer math when no typed path exists (e.g., walking the GNameBlocks table in `UEFNameSummaryProvider`, where the underlying storage is an untyped block array).