C.CodeCompared.To/Lua

print is a global function that appends a newline, so there is no \n to remember. It also needs no header: Lua's standard library is already loaded into the global environment when the interpreter starts.

print separates its arguments with a tab and calls tostring on each one, so it never has to be told what type anything is. string.format uses the same conversion specifiers as printf, including width and precision.

The long-bracket syntax [[ ... ]] is the same one used for multi-line string literals; a comment is just a long bracket preceded by --.

This example cannot run here: the browser runner hands a string straight to the interpreter rather than launching lua script.lua …, so there is no arg table to read. Run it with lua example.lua one two three locally to see the output.

This is the single most common source of bugs in Lua code written by C developers. Always write local. Globals are entries in a table (_ENV), so they are also slower to read than locals, which the compiler resolves to a register slot.

Nothing checks this at compile time, so a typo that in C would be a diagnostic becomes a runtime error in Lua — usually attempt to perform arithmetic on a string value, and only when that line is finally reached.

A local is visible from its declaration to the end of the enclosing block, which means a local declared later in the same block is genuinely not in scope earlier — the same rule C uses.

Any names left over receive nil, and any surplus values are discarded — no length check, no error. This same mechanism receives the multiple return values of a function call.

This is a deliberate simplification, not an oversight — Lua adds an operator only when it earns its keep in the grammar. Bitwise compound forms (&=, |=) are missing for the same reason.

The eight types are nil, boolean, number, string, function, table, userdata, and thread. userdata is the interesting one for a C developer: it is a block of raw memory owned by the host program, which is how a C struct is handed to Lua.

Because a missing table key reads as nil, there is no distinction between "absent" and "set to nil" — assigning nil to a key removes it. There is also no uninitialized memory in Lua: a fresh local starts as nil, never as garbage.

A ported if (count) therefore silently takes the wrong branch instead of failing loudly. Write if count ~= 0 then and if text ~= "" then explicitly. The upside: if value then is an unambiguous "is this present?" test, with no confusion between a legitimate zero and a missing value.

a and b yields a when a is falsy and b otherwise; a or b yields a when a is truthy and b otherwise. Both short-circuit like C's && and ||. The one trap: condition and false or other misbehaves, because a legitimately false middle operand falls through to the or.

There is no unsigned, no short, and no size_t: an integer is always 64-bit and signed. Values move between the subtypes automatically, and arithmetic that cannot be exact in integers produces a float. Before Lua 5.3 there was only the double, which is why some older embedded builds still have no integer subtype at all.

For negative operands the two languages genuinely disagree: C gives -7 / 2 == -3 and -7 % 2 == -1, Lua gives -4 and 1. Lua's rule is the mathematically consistent one (a == (a // b) * b + a % b always holds), but ported code that relies on C's truncation needs checking.

Note also that ^ is exponentiation in Lua, not bitwise XOR, and it always returns a float — 2 ^ 10 is 1024.0. Bitwise XOR is ~, which doubles as bitwise NOT in its unary form.

Because every integer is signed, shifts are logical rather than arithmetic: >> fills with zeros, so shifting a negative value right does not preserve its sign the way C's implementation-defined >> on a signed type usually does. Shift counts of 64 or more produce 0 rather than the undefined behavior C would have.

math.fmod is deliberately kept alongside % because they differ: fmod truncates like C's %, while the % operator floors. Reach for math.fmod when porting C code whose remainders must keep the dividend's sign.

Because they are immutable, Lua interns strings: two identical strings are usually the same object, so equality is a pointer comparison rather than strcmp. And because the length is stored rather than found by scanning for a NUL, a Lua string may contain embedded zero bytes and still work with every string function.

# counts bytes, not characters — a UTF-8 string of three accented letters has a length above three. Lua 5.3 added a utf8 library (utf8.len, utf8.char, utf8.codepoint) for when the distinction matters.

Numbers are coerced to strings by .., which is the one place Lua does implicit conversion cheerfully. Watch the spacing though: 1..2 is a syntax error because the lexer tries to read 1. as a number, so write 1 .. 2.

Two differences worth knowing: there is no buffer to overflow, so no snprintf-versus-sprintf decision to make; and Lua adds %q, which escapes a value so that reading it back as Lua source reproduces it exactly. A mismatched specifier raises a clear runtime error rather than reading whatever the stack happened to hold.

Note the method-call syntax: text:sub(3, 5) is sugar for string.sub(text, 3, 5), available on every string because strings share a metatable whose __index is the string table. Out-of-range bounds are clamped rather than being undefined behavior.

Patterns use % where regular expressions use a backslash: %w is alphanumeric, %a alphabetic, %d a digit, %s whitespace, and capitals negate the class. There is no alternation (|) and no bounded repetition ({2,4}); the payoff is that the whole engine is a few hundred lines of C with no backtracking blowups.

Reading a key that was never set gives nil rather than garbage, so there is no out-of-bounds read to exploit. Under the hood the implementation still keeps consecutive integer keys in a real array, so numbers[i] is a bounds-checked array access, not a hash lookup.

table.insert(numbers, value) does the same thing and reads more clearly when you also use the two-argument form to insert in the middle. Allocation failure is not something the script sees at all — Lua raises an error the host can catch instead of returning a null pointer.

released.lua is exactly released["lua"] — the dot is sugar for a string key. Iteration order from pairs is unspecified and can change between runs, so never rely on it; use an array of keys and table.sort when order matters.

There is no layout to reason about, no padding, and no sizeof. The cost is that field access is a hash lookup rather than a fixed offset, and that origin.lable = 1 silently creates a second field instead of failing to compile.

Both functions work on the array part (keys 1..n) and keep it dense, which is what lets # stay meaningful. table.remove(numbers) with no position pops the last element — the cheap operation, since nothing has to shift.

Use ipairs (or a numeric for) whenever the sequence matters, and pairs when the table is a record or a map. pairs on an array works but gives no ordering guarantee — a subtle bug when output order is part of what you are testing.

The comparator must be a strict order: returning true for equal elements makes table.sort raise invalid order function for sorting rather than silently producing nonsense. The sort is in place and not stable, exactly like qsort.

There is no ! operator either — negation is the word not. Remember that the condition is tested for truthiness, so if score then is true even when score is 0.

This is often better than the C original: there is no fallthrough to forget a break for, the cases can be any type rather than only integers and characters, and the table can be built at runtime or extended by other code.

The control variable is a fresh local in each iteration and assigning to it does not affect the loop — closures created inside the loop each capture their own copy, which is the opposite of C where they would all share one variable. The limit is inclusive, so for index = 1, #items covers the whole array.

One nicety Lua adds: locals declared inside the repeat body are still in scope in the until expression, so you can compute a value and test it without hoisting the declaration above the loop.

Lua's goto is far more restricted than C's: it cannot jump into or out of a function, and it cannot jump into the scope of a local. That rules out most of the ways goto gets abused in C, including the goto cleanup pattern — which Lua does not need anyway, since errors unwind through pcall.

local function doubled is sugar for local doubled; doubled = function… — declaring the local first, which is what lets the body call itself recursively. Writing local doubled = function… instead leaves the name out of scope inside the body.

This is why string.find can return a start and an end, and why pcall can return a success flag plus the result. The rule to remember: a call in the middle of an expression list is truncated to one value, and wrapping a call in parentheses truncates it too.

Packing varargs into a table with { ... } is convenient but stops at the first nil; select handles embedded nils correctly, and table.pack(...) gives a table with an explicit n field. There is no undefined behavior for a mismatched type — a bad value raises an error where it is used.

The captured variable is called an upvalue, and each closure gets its own — separate above shares nothing with add_to. This is the mechanism behind iterators, callbacks, and Lua's object idioms, and it is the single largest expressive gap from C.

Since there is no signature to satisfy, a higher-order function like apply_twice works with anything callable — including a closure carrying its own state, or a table with a __call metamethod. Arity is not checked either: missing arguments arrive as nil and extras are discarded.

The caveat is the same one that applies to every or default: false is falsy, so a caller who genuinely passes false gets the default instead. When that matters, test if flag == nil then explicitly.

What you give up is control over when memory is released, which matters for a hard-real-time loop; what you gain is the entire class of bugs that never happens — no leak, no double free, no use-after-free. The collector is written in the same portable C as the rest of the interpreter, and the host can even supply its own allocator via lua_newstate.

Dropping the last reference (assigning nil) makes a value collectable but does not destroy it — anything else still holding it keeps it valid. That is why there is no equivalent of freeing a block that another part of the program is still using.

Numbers, booleans, nil, and strings behave like C values (strings are immutable, so sharing them is unobservable). Lua has no built-in copy — write the loop above for a shallow copy, and recurse for a deep one. This is the same surprise a C developer gets from passing a struct pointer where a struct was meant.

collectgarbage("count") returns kilobytes in use, ("collect") forces a full cycle, and ("step") runs one increment — useful in a game loop that wants to bound collector pauses. An embedding host has the same control from C through lua_gc. This is the one example on the page the browser cannot run: Fengari leaves lua_gc unimplemented, because the JavaScript engine underneath owns collection. Run it under a local lua and the numbers are real.

That is the whole trick: obj:method(a) is sugar for obj.method(obj, a), and a "method" is just a function stored in a table field. Using a dot where you meant a colon is the resulting classic bug — self arrives as the first real argument instead.

There are no classes in the language at all; every OOP system in Lua is a convention built on __index. The lookup only happens when the key is absent, so an instance can override an inherited method simply by having its own field of that name.

The metamethod is looked up on the operands' metatables, so it applies to every value sharing that metatable rather than to a type declaration. __eq is consulted only when both operands are tables (or both userdata) that are not already the same object — comparing a table to a number is simply false, never an error.

Without __tostring a table prints as table: 0x55f3… — its address, which is occasionally what you want when checking identity. __name in the metatable improves the default and the error messages that mention the type.

This is the mechanism behind read-only tables, proxy objects, and lazy loading. Its counterpart __newindex intercepts assignment to a missing key, which is how you make a table reject unknown fields — recovering, by convention, the compile-time error C would have given for a misspelled struct member.

Errors are values, not a separate mechanism: error("text") raises a string (with position information prepended), and error(value, 0) raises it unchanged. Library functions that fail for expected reasons still use the C-like convention of returning nil, message — io.open is the canonical example.

Because pcall takes the function and its arguments rather than a block, wrapping several statements means passing an anonymous function: pcall(function() … end). This is also the mechanism a C host uses at the boundary — lua_pcall is the same protected call, seen from the other side.

It is never compiled out, so an assert in a hot loop is a real check with a real cost. The idiom local handle = assert(io.open(path)) converts the nil, message convention into a raised error in one step.

The classic handler is debug.traceback, giving xpcall(work, debug.traceback) — a stack trace at the point of failure rather than at the point of catching, which no pcall can reconstruct afterward. Note that a table error message means error(problem) adds no position information, since that is only prepended to strings.

There is no separate declaration of a module's interface, so nothing can go out of sync between a header and its implementation, and no include guards are needed. A module is a value you bind to a local name of your choosing, which also means two modules can never collide in a global namespace.

That removes the whole macro hazard list: no double evaluation of arguments, no missing parentheses changing precedence, no token pasting to debug. The trade-off is real but small — dead code is still compiled and shipped, and there is no equivalent of building out a platform-specific branch entirely.

Neither column runs here: the browser has no filesystem for module search and no compiler for the C side. What matters for an embedder is that a C extension is a shared library exporting luaopen_name, which require loads through package.loadlib and calls to get the module table.

luaL_newstate uses realloc/free; lua_newstate takes your own allocator instead, which is how game engines route Lua through their pool allocators. luaL_openlibs is optional — leave it out and the script gets no libraries at all, a cheap first step toward sandboxing untrusted scripts.

The stack is why the C API needs no lua_Value type and no reference counting: a value sitting on the stack is reachable, so the collector will not move it out from under you. The discipline it demands is balance — leave the stack as you found it, and use lua_gettop/lua_settop when a function has several exits.

lua_getglobal pushes the value and returns its type, so a host that cares about a missing or misspelled setting should check for LUA_TNIL instead of silently taking lua_tointeger's 0. Reading a global from C is a table lookup in _G, the same operation the script performs.

Use lua_pcall, not lua_call: an uncaught error in a plain lua_call propagates past your C frame (a longjmp) and never returns, so any cleanup after it is skipped. Pass LUA_MULTRET as the result count to accept however many the function returns, then use lua_gettop to see how many arrived.

From Lua's side there is no difference: type(clamp) is "function" either way, and the script cannot tell that this one is native. This is how an engine exposes its own systems — rendering, physics, entity queries — without generating bindings or writing FFI declarations.

These functions do not return on failure — they longjmp out of your C frame — so any resource you acquired before calling them leaks. Acquire nothing until the arguments are checked, or use luaL_optinteger for optional arguments with a default. Note that the script catches a C-raised error with pcall exactly as it would a Lua one.

Returning 0 means the call evaluates to nothing (not to nil — the difference shows up in select("#", …)). The count must match what you actually pushed: claiming more than you pushed hands the script whatever was underneath on the stack.

Shipping this as a loadable module means compiling it as a shared library whose one exported symbol is luaopen_rectangle, doing the luaL_newlib and returning 1. Then require("rectangle") finds it on package.cpath and the script cannot tell it from a Lua module.

The type check matters — without it a script could pass any userdata and your C code would reinterpret unrelated memory. If the struct owns resources Lua does not know about (a file handle, a socket, a malloc'd buffer), add a __gc metamethod to release them when the userdata is collected; that is the one place an embedder still writes cleanup code.

Under the hood a raised error is a longjmp to the nearest protected call, so C code between the two is skipped entirely — no destructors, no cleanup. That is why the API discourages holding resources across a call that can raise, and why the standard advice is to keep C functions short and let Lua own the control flow.

The C column here is a set of shell commands rather than a program, so it does not run. Worth knowing: the C API is source compatible across minor versions but not binary compatible, so a host built against 5.3 must be recompiled for 5.4 — and lua_newuserdatauv in the userdata example above is one of the 5.4 additions that will not compile against 5.3.

This is cooperative and single-threaded — no preemption, no locks, no data races, and nothing resembling pthread_create. The nearest C equivalents are setjmp/longjmp (which cannot resume a frame it left) or a real thread per task (vastly more expensive). coroutine.status reports suspended, running, normal, or dead.

The difference from the C version is where the state lives: in the coroutine's own suspended stack rather than in a struct you defined and advanced by hand. wrap also propagates errors instead of returning a status the way resume does, so a failure inside the generator surfaces at the loop.

Values pass in both directions — coroutine.resume(co, value) supplies the result of the yield inside, which is how a coroutine-based scheduler feeds work back to a task. This is the same mechanism behind Lua's use in async I/O libraries and in game engines that suspend a script mid-behavior for several frames.

The resolution of os.clock is whatever the C library provides, which is not enough for microbenchmarks — embedders usually expose a high-resolution timer as a C function instead. os.time also accepts a table of date fields, filling the role of mktime.

The table it returns uses natural values rather than C's offsets — year is 2001, not 101, and month is 1..12 rather than 0..11 — so tm_year + 1900 has no counterpart. There is no buffer to size, and an unknown specifier raises an error instead of being silently dropped.

This Lua example cannot run in the browser: Fengari has no filesystem, so it omits the io library entirely apart from a shim for io.write. Run it under a local lua to see it work. Also note io.open returns nil, message on failure rather than raising, which is what assert is converting here.

This matters for performance, not just tidiness: strings are immutable, so result = result .. piece in a loop allocates and copies the whole accumulated string every iteration. table.concat walks the pieces once, sums their lengths, and allocates the result exactly once.

The convention runs through the whole standard library: string.sub, table.insert, string.find, and %1 captures all count from 1. Tables can hold a key of 0 perfectly well, but it is outside the array part that # and ipairs consider.

The usual defenses are a linter (luacheck) and, at runtime, a __index/__newindex metatable on _G that raises on unknown globals — a few lines that turn this class of typo back into a loud failure. Embedders often install exactly that in the state they hand to scripts.

The same applies to while (remaining) loops and to if (pointer) null checks — the latter becomes if value ~= nil then, or just if value then once you know the value is never false.

The practical rules: remove from the middle with table.remove (which closes the gap) rather than by assigning nil, and count with pairs when gaps are possible. This is also why ipairs stops at the first missing index — it is walking a sequence, and the sequence has ended.

The one normalization Lua does perform is float-to-integer: t[2.0] and t[2] are the same key, since the float has an exact integer value (and t[2.5] is simply its own key). nil and NaN are the only values that cannot be keys at all.