Skip to main content

set_versioned_registry_slots

Function set_versioned_registry_slots 

Source
pub fn set_versioned_registry_slots(
    state: &mut LuaState,
) -> Result<(), LuaError>
Expand description

Populate the version-dependent numeric registry slots — the main thread and the globals table — for the current lua_types::LuaVersion.

Which index holds what changed across the Lua line, so this is gated on the active version (all indices verified against the reference binaries):

  • 5.1 — no numeric registry convenience indices at all; globals live in the per-thread environment (fenv), not the registry, and there is no LUA_RIDX_MAINTHREAD. debug.getregistry() has no numeric keys.
  • 5.2 / 5.3 / 5.4registry[1] is LUA_RIDX_MAINTHREAD (the main thread) and registry[2] is LUA_RIDX_GLOBALS (the globals table). registry[3] is the luaL_ref free-list head (freelist = LUA_RIDX_LAST + 1; see lua_ref in lua-stdlib) and is NOT written here.
  • 5.5LUA_RIDX_MAINTHREAD was renumbered to 3; registry[2] is still the globals table; and registry[1] is initialized to false, which is the luaL_ref free-list head’s “uninitialized” sentinel in C 5.5 (luaL_ref accepts nil or false there before its first use), not a placeholder reserved for some future index.

STARTUP-ONLY. This must run during VM bootstrap, before any user code or luaL_ref call touches the registry. It is called twice in practice (once from init_registry at the default version, once from the version-selecting entry point once the real version is set). To make that second call safe it clears a slot only when the slot still holds a value this function itself wrote at the earlier default version (the main-thread handle or the globals table) — never an arbitrary entry, so a luaL_ref free-list head would survive. It is NOT a general reset and is NOT safe to call after luaL_ref/user code has begun using the registry: the 5.x set paths still overwrite registry[1..=3] with fixed values, which post-startup could clobber a live reference. Do not expose it as such.