Lua.CodeCompared.To/C

Nothing in the C version is optional. Drop #include <stdio.h> and the compiler has never heard of printf; drop the \n and the newline never appears, because printf writes exactly the bytes you give it and nothing more.

The practical consequence is that a C mistake is caught at build time by a compiler that refuses to produce a binary, whereas a Lua mistake waits until the line actually executes. That trade is the whole reason the type declarations in the next section exist.

C block comments do not nest, so wrapping a region that already contains /* … */ ends the comment early and leaves a stray */ the compiler rejects. Lua's long comments can be given extra equals signs (--[==[ … ]==]) to nest safely, which is the closest either language comes to a comment you can wrap around anything.

The %s and %d in printf are a preview of the strings section: C has no way to print a value without being told its type, whereas Lua's print inspects each argument at run time and separates them with a tab on its own.

A C variable cannot later hold a different kind of value. Assigning count = "items" is not a run-time surprise as it would be in Lua — it is a compile error, and the program is never produced.

This is the single largest adjustment coming from Lua. A C variable is a fixed-size, fixed-type box at a known location, and the type is how the compiler decides how many bytes to move and how to interpret them.

Reading it is undefined behavior, which is worse than a wrong answer — the compiler is entitled to assume it never happens and optimize accordingly. Always write the initializer; there is no nil to fall back on.

Using inner outside its block is a compile error in C and a silent nil in Lua. Note too that C has no equivalent of Lua's global-by-default rule — there is no way to accidentally create a variable by assigning to an undeclared name, because the declaration is mandatory.

The missing multiple assignment has a larger consequence further down this page: it is also why C functions cannot return more than one value, and why out-parameters exist.

The comparison is still true in C, because the int is converted to double before comparing. That implicit conversion is convenient here and the source of real bugs elsewhere, as the division row shows.

This is the most common numeric bug for a Lua programmer writing C. 7 / 2 silently yields 3 — no warning, no float — and the usual repair is to cast one operand, as the third line does.

The example uses unsigned int deliberately: unsigned overflow is defined to wrap, while signed overflow is undefined behavior in C, not a wrap. A signed INT_MAX + 1 is not merely a surprising number — it licenses the compiler to do anything at all. 🚨 Fengari, which runs the Lua column in your browser, uses 32-bit integers, so clicking run here prints 2147483647 rather than the 64-bit maximum a desktop lua reports. The language specifies 64-bit integers; this build does not provide them.

"10" + 5 in C is pointer arithmetic: it produces a pointer five bytes into a two-byte string, and using it reads past the end. Conversion must be explicit — atoi here, or strtol when you need to detect failure. One browser caveat: Lua 5.3 makes string-to-number coercion produce a float, so Fengari prints 15.0 where a 5.4-or-later desktop lua prints 15. The coercion happens either way; only the subtype differs.

The trap is not the literal 0 but the function that returns a count. if (strlen(name)) is true for a non-empty name and false for an empty one, which is the opposite of what the same shape does in Lua.

This is why C functions so often return a status separately from their result, and why an int result frequently reserves -1 to mean failure. There is no out-of-band value the way nil is out-of-band for every Lua type.

C's ? : is a genuine conditional expression and is the direct equivalent of Lua's and/or idiom — with one advantage: it works correctly when the middle value is false, which ready and false or "no" famously does not.

The cost matters in loops. Writing for (size_t index = 0; index < strlen(text); index++) re-scans the whole string on every iteration, turning a linear loop into a quadratic one. Compute the length once, before the loop.

Note char greeting[] rather than const char *greeting. The array form copies the literal into modifiable storage; writing through a pointer to a string literal is undefined behavior and typically crashes, because literals usually live in read-only memory.

Use snprintf rather than strcat or sprintf. It takes the buffer size and refuses to write past it, which is the difference between a truncated string and a buffer overflow — historically the most exploited bug class in C.

Use strcmp, and remember it returns 0 for equal. Combined with the zero-is-false rule above, if (strcmp(a, b)) reads as "if equal" and means the exact opposite — a classic first-week C bug.

strtok_r writes NUL bytes over the delimiters in sentence, which is why the input has to be a modifiable array rather than a literal. For anything resembling a real pattern you reach for POSIX <regex.h> or a third-party library.

This is why C cannot hold arbitrary binary data in a plain string, and why any API that deals with binary takes a pointer and a length. Lua needs no such convention, which is one reason it is a comfortable place to do binary parsing.

Nothing checks the index. Writing values[3] compiles, runs, and silently overwrites whatever happens to sit after the array — a neighboring variable, a saved register, a return address. This is the single most important safety difference on the page.

Mixing the two conventions produces the off-by-one that reads or writes one slot past the end. Because C does not check, the symptom appears somewhere else entirely — often long after the line that caused it.

The sizeof values / sizeof values[0] idiom works in main and would be wrong inside total, where sizeof numbers is the size of a pointer. This is why essentially every C function taking an array also takes a count.

Looking a key up here is a linear scan with strcmp. That is genuinely what small C programs do, and it is a fair reminder of how much work a Lua table is quietly doing every time you write settings.width.

That is why the parameter can be written int *numbers and why sizeof on it gives a pointer size. Everything else in C is copied on the way in, including whole structs; arrays are the one exception.

The .x = 3 form is a designated initializer, added in C99. It is worth preferring over positional { 3, 4 } for the same reason Lua programmers prefer named fields: the meaning survives a reordering of the declaration.

Struct assignment and struct arguments both copy every byte, so passing a large struct by value is real work. C code therefore passes a pointer (struct Point *) when the struct is big or when the callee needs to modify it — which restores the Lua behavior you started with.

The -> operator is (*self).count written shorter. Seeing self spelled out as a parameter is a useful reminder of what counter:increment() desugars to in Lua — the two languages differ in notation here more than in mechanism.

Nor is there any equivalent of __index, so there is no way to intercept a missing field, and no way to give a struct a default. What you declare is what exists.

Three failure modes have no counterpart in Lua: forgetting free leaks; calling it twice corrupts the allocator; and using the pointer afterwards reads memory that now belongs to something else. Note also that malloc can return NULL, so the check is not optional.

Returning the address of a stack local is the classic beginner error — it compiles, and the pointer is dangling before the caller can use it. If a value must outlive its function, it must be on the heap, and then somebody must free it.

The convention lives in a comment and in the function's name, which is why C libraries document ownership so obsessively and why mismatched expectations between two libraries are such a common source of leaks and double frees.

Setting record = NULL after freeing protects that one variable and does nothing for alias, which still holds the old address. Nothing in the language will tell you; the read simply returns whatever now occupies that memory.

Note that realloc's result is assigned to a new variable first. Assigning it straight back to values would leak the original block on failure, because realloc returns NULL without freeing what you gave it.

C has no collector, so it has no pause and nothing to tune — which is precisely why performance-sensitive parts of a Lua application get rewritten in C. You trade the risk of a collection at a bad moment for the risk of getting the frees wrong. The Lua column is shown rather than run here because Fengari, which executes this page in your browser, does not implement collectgarbage — it reports lua_gc not implemented and leaves collection to the JavaScript engine underneath it.

Braces are optional around a single statement, and omitting them is how the notorious goto fail bug happened. Write them always; every C style guide worth following says the same.

Because the test is written out, the inclusive/exclusive choice is yours: <= 5 here matches Lua's inclusive limit, while the far more common < count pairs with zero-based indexing.

The conditions are therefore negations of one another — until attempts >= 3 becomes while (attempts < 3). Translating one to the other without flipping the test is an easy and silent mistake.

C's switch only works on integer types, which is why the string command had to become a number; dispatching on a string still means an strcmp chain. And every case needs its break, or control falls through into the next one.

The static keyword limits the function to this one source file, which is C's nearest equivalent to a local function. Without it the name is visible to every other file in the program and can collide at link time.

This inverts what the return value is for: in Lua it is the answer, in C it is very often the status, with the answer written through a pointer. Reading result without checking the status first is how uninitialized values spread.

This is why C callback APIs almost always take a void *user_data alongside the function pointer — that parameter is the hand-rolled replacement for the captured variable. The three calls are also written as separate statements deliberately: C does not define the order in which a single call's arguments are evaluated, so putting all three inside one printf could legally print them in any order.

The declaration int (*transform)(int) reads outward from the name: transform is a pointer to a function taking an int and returning an int. Note also that the results array is supplied by the caller, because apply has nowhere to allocate one without deciding who frees it.

That is why printf needs a format string — it is the only thing telling the function how many arguments to read and how to interpret each one. A mismatched format specifier reads the wrong number of bytes off the stack, which is why compilers special-case printf and warn about it.

C also has no function overloading: two functions cannot share a name, which is why the standard library is full of families like strcpy and strncpy rather than one name with optional parameters.

The consequence is that C error handling is opt-in at every level. Ignoring the return value of a function that can fail is legal and silent, which is exactly why so much C code checks nothing and then behaves strangely later.

Note that strtol does not use errno to signal "not a number" at all: it reports that through the unparsed pointer, and reserves errno for range errors. Every C function documents its own convention, and there is no rule covering all of them.

C's assert is a macro that calls abort() — no catching, no cleanup — and compiling with -DNDEBUG removes it entirely. It is for catching programmer mistakes during development, never for validating input that might legitimately be wrong.

In C the value returned from main is that status, so return 0 at the end of every example on this page is not decoration. exit(1) from <stdlib.h> does the same thing from anywhere in the program, matching Lua's os.exit. The Lua column here is shown rather than run: there is no process to leave in the browser, and Fengari's os.exit tears down the interpreter that the rest of the page depends on.

Because it is textual, a macro has no type and no scope, obeys no block rules, and is invisible in a debugger. Modern C style prefers const int or an enum for plain constants and keeps #define for things a variable cannot express.

Hence the rule that every macro parameter and the whole body get their own parentheses. A second hazard has no fix at all: a macro that uses its argument twice will evaluate it twice, so DOUBLE_OK(count++) increments count two times.

This is how one C source file supports several platforms, and it is why C code often needs to be read twice: what the compiler sees depends on which macros were defined, so the file on screen may not be the program that was built.

A header carries only declarations — promises that a function exists somewhere with a given signature. The actual machine code for printf is not in stdio.h; it is in the C library, and the linker connects the two after compilation.

Keeping the two in agreement is the programmer's job, and a header that has drifted from its source is a familiar C bug. Nothing like it can happen in Lua, where the function and its name are the same object.

C resolves everything before the program starts: -I tells the compiler where headers are and -l tells the linker which libraries to bind in. There is no equivalent of adding a search path at run time short of dlopen, which is a separate mechanism entirely.

Note the signature: every C function Lua can call takes a lua_State * and returns an int. That integer is not a status — it is the number of return values the function left behind, which is how C manages to return the multiple values it otherwise cannot.

lua_gettop returns how many arguments were passed, which is C's answer to select("#", ...). Negative indices count from the top, so -1 is the last argument — a convention with no parallel in either language's ordinary code.

These functions do not return on failure: they perform a long jump out of your C function. Anything you allocated with malloc beforehand is therefore leaked, which is why argument checking belongs at the very top of the function, before any resource is acquired.

The loop also shows the stack discipline the API demands. lua_geti pushes the element, lua_tointeger reads it at index -1, and lua_pop removes it — forget the pop and the stack grows by one on every iteration.

The { NULL, NULL } at the end is the terminator — the array does not know its own length, the same limitation the arrays section described, showing up in a real API. In a shared library the entry point would be luaopen_geometry returning 1, and require("geometry") would find it by name.

It is lua_pcall rather than lua_call for the reason the error-handling section gave: an uncaught Lua error long-jumps, and if it crosses a plain lua_call in C it will unwind past your cleanup code. lua_pcall returns a status instead, which is C's pcall.

The condition becomes the assigned value, so if (value = 1) is always true and if (value = 0) is always false — and the variable is quietly modified either way. Compilers warn about it with -Wall, which is a strong argument for always building with warnings on.

The fix is to make one operand a floating-point value — 2.0 here — so the division itself is done in floating point. Coming from Lua, where / always produces a float, this is the easiest wrong answer on the whole page to walk past.

On a 64-bit machine it yields 2 — an 8-byte pointer divided by a 4-byte int — which is a plausible-looking number, not an obvious error. This is why the count is a parameter in every well-written C function that takes an array.

The format string is the only description of the arguments, so a mismatch reads the wrong number of bytes and everything after it is garbage too. Compilers do check literal format strings with -Wformat (included in -Wall), which is the only reliable defense.