为何C语言无内部函数，但以C实现的Lua等语言却支持内部函数？

Great question—this cuts straight to the core of how language execution models and design priorities shape what features they can support, even when one language is built on top of another! Let’s unpack this clearly:

1. Virtual Machine vs. Native Compilation: The Big Difference #

• Lua runs on its own custom virtual machine (VM). When you define an inner function in Lua, it’s not translated directly to a fixed native machine code address at compile time. Instead, the VM creates a closure—a bundle of the function’s bytecode plus references to the variables from its enclosing scope (called "upvalues" in Lua). This all happens at runtime, so the VM can dynamically track and access those captured variables whenever the inner function is called, even after the outer function has finished executing.
• C, by contrast, compiles directly to native machine code tied to fixed memory addresses. C functions are resolved during compilation or linking; there’s no built-in way to attach runtime state (like outer scope variables) to a function. The compiler assumes function calls are direct jumps to known addresses, with no need to carry around extra context.

2. Scope and Variable Persistence #

• Lua uses lexical scoping with first-class functions. Inner functions can "close over" outer variables because the VM manages variable storage in a way that lets those variables persist if an inner function still references them—they’re not just dumped when the outer function exits (unlike C’s stack-based local variables).
• C has static scoping but no support for first-class functions that capture state. All C functions live in global or file scope; there’s no way to tie a function to the local variables of another function. Even if you use function pointers, you can’t safely capture stack variables—once the outer function returns, that stack memory is reclaimed, leading to dangling references.

3. Can C be forced to support inner functions with a large codebase? #

Sort of—but it’s not extending native C; it’s building a Lua-like runtime on top of C. Here’s how:

• You’d need to implement a custom runtime that manages closures: creating data structures to hold function pointers plus captured variables, handling dynamic memory for those variables, and adding logic to resolve variable access at runtime.
• Projects like Wren (a small VM language written in C) or libraries that add closure support to C (using things like libffi with custom scope management) do exactly this. But this isn’t making C itself support inner functions—it’s creating a new language layer that runs on top of C’s native capabilities.

To sum it up: Lua’s inner functions are a feature of its runtime and type system, not something C’s native compilation model can support out of the box. C is powerful enough to build the infrastructure for inner functions (as Lua proves!), but native C can’t have them as a core language feature without a total rewrite of how it compiles and executes code.

内容的提问来源于stack exchange，提问作者Hatefiend