OCaml.CodeCompared.To/C

OCaml's let () = … both runs the expression and asserts it produces nothing. C requires a function literally named main, and the int it returns becomes the process exit status — return 0 means success. The #include is not an import: it is a textual paste of stdio.h into this file before compilation, which is why the preprocessor gets its own section. Note also that the newline is part of the string; printf adds nothing, unlike print_endline.

OCaml took printf's directives from C and made them part of the type system: "%s appeared in %d" is a value of the built-in format type, and passing the wrong argument types is a compile error with no way around it. C's format string is an ordinary char *, and printf is variadic with no type information at all — passing an int for %s compiles and reads that integer as a pointer, which is undefined behavior. GCC and clang do check literal format strings (-Wformat, on under -Wall), and that check is a courtesy from the compiler rather than a rule of the language.

C has no package manager and no module system. A dependency is two separate things that must both be arranged: a header giving the compiler declarations (-I) and a compiled library giving the linker definitions (-L, -l). Nothing checks that the header you compiled against matches the library you linked, which is a whole class of bug OCaml cannot have. The compilation model is also genuinely different: dune reads your modules and works out the order, while make is told each step explicitly and every .c file is compiled in isolation, seeing only what it has #included.

OCaml infers count : 'a list -> int and generalizes it, so one definition works for lists of anything. C has neither inference nor parametric polymorphism, so the element type is nailed down and a version for a different type is a second function. The (void)items; line is there to silence an unused-parameter warning under -Wextra, and is worth noticing as an idiom you will write often. The generic-programming section covers what C does instead, and it is not pretty.

An OCaml int is 63 bits on a 64-bit platform — one bit is the garbage collector's tag — and it wraps silently. C gives you char, short, int, long, long long and unsigned versions of each, with only minimum widths guaranteed, which is why stdint.h exists and why int32_t and int64_t are what portable code uses. The rule that matters most: unsigned overflow wraps and is defined; signed overflow is undefined behavior, meaning the compiler may assume it never happens and optimize accordingly. That is not a wrapped value — it is a program with no defined meaning.

OCaml is immutable by default and you opt in with mutable or a ref. C is mutable by default and you opt out with const — which qualifies exactly one level: const int * is a changeable pointer to unchangeable ints, and int * const is the reverse. The example shows the consequence: readable promises not to write through itself, and the underlying array is still writable through another name, so the second print shows 99. const is a statement about that access path, not about the object.

OCaml's type coordinate = int is also an alias and interchanges freely — but OCaml can make a distinct type when you want one, either with a single-constructor variant or by hiding the definition behind a signature. C's typedef is only ever an alias: coordinate and int are the same type, so mixing them is silent. The typedef struct { … } point; form above is also worth learning because it lets you write point rather than struct point everywhere, which is what most C code does.

OCaml controls visibility with a signature: an .mli file lists what a module exports, and anything not listed is inaccessible and can be inlined or removed. C's static at file scope gives a declaration internal linkage, meaning other translation units cannot refer to it — which is the same idea with far less granularity, since there is no way to expose something to one file and not another. Note the overloaded keyword: static inside a function means something completely different, namely a variable that persists between calls, which is a hidden global with all the problems that implies.

OCaml's collector means allocation is a bump of a pointer and deallocation is something you never think about. C gives you malloc, which can fail and returns NULL when it does, and free, which you must call exactly once for every successful malloc. Calling it zero times leaks; calling it twice corrupts the allocator; using the pointer afterwards reads memory that may already belong to something else. None of those is an error the language reports — the tools that find them are the sanitizers (-fsanitize=address) and Valgrind, and running under them is not optional in serious C.

OCaml puts almost everything on the heap and lets the collector sort out lifetimes, so a locally constructed record can be returned without a thought. In C a local lives on the stack frame, which is reclaimed the instant the function returns — so returning the struct by value (a copy) is fine, and returning &result gives a pointer to memory that the next function call will overwrite. Compilers warn about the obvious case; they cannot warn about the version where the pointer is stored in a struct first. Returning heap memory means malloc, and then the caller owns it and must free it — which is why C APIs document ownership in comments.

In OCaml the question does not exist. In C every function returning a pointer has an ownership convention — the caller frees it, or the callee retains it, or it points into a buffer the caller already owns — and the convention is expressed only in a comment or a manual page. Getting it wrong leaks or double-frees, and the compiler cannot help because the type char * is identical in all three cases. This is exactly the problem Rust's ownership system was designed to move into the type system, and it is the single largest source of memory bugs in C.

OCaml's Buffer — and Dynarray in 5.2 — manages capacity for you. In C you track length and capacity separately and call realloc, which may move the block, so every existing pointer into it becomes invalid. The temporary variable in the example is the standard idiom and matters: writing numbers = realloc(numbers, …) loses the original pointer when realloc returns NULL, leaking the whole buffer at the exact moment memory was already short.

The C column is what 1 :: 2 :: 3 :: [] builds: a chain of two-word blocks, each holding a value and a pointer to the next, with NULL standing in for []. Consing is one allocation and a pointer write, which is why it is O(1); List.length walks the chain, which is why it is O(n). The teardown loop is the part OCaml never makes you write, and note the shape of it: you must save next before freeing the node, because reading a freed node's field is undefined behavior. That single ordering constraint is behind a great many real-world crashes.

OCaml's ref is an ordinary record { mutable contents : 'a }, so ref 0 allocates a box on the heap and passing it around passes the box. C's &counter takes the address of an existing stack variable, so no allocation happens and the callee writes directly into the caller's frame. The syntax is a near-mirror — !cell reads, *cell reads; cell := x writes, *cell = x writes — which makes the difference easy to miss. The one that has no OCaml counterpart is what comes next: a pointer is a number you can do arithmetic on.

An array name in C decays to a pointer to its first element in almost every context, and cursor++ advances by sizeof(int) rather than by one byte — the arithmetic is scaled by the pointed-to type. That is how the standard library is written and how you will read most C. It is also completely unchecked: nothing stops cursor running past end, and doing so is undefined behavior rather than an exception. OCaml has no pointer type in the language at all; indexing is the only access, and numbers.(index) raises Invalid_argument on an out-of-range index.

OCaml's int option is a different type from int: you cannot use the value without unwrapping, and a missing branch is a compile-time warning naming it. C's NULL is a value of the very same pointer type, so *found compiles whether or not the check is there, and dereferencing NULL is undefined behavior — a segmentation fault on a normal machine, and something less predictable when the compiler has optimized around the assumption that it cannot happen. The discipline is to check every pointer that may be null immediately, at the point it is produced.

The rule generalizes: to let a function change something the caller holds, pass the address of that thing. If the caller holds an int, pass int *; if it holds an int *, pass int **. That is all a double pointer is, and it appears constantly in list manipulation and in functions that allocate on the caller's behalf. OCaml never needs it because nothing is modified in place — a function returns the new value and the caller rebinds, which is the same information flowing the other way.

An OCaml string knows its own length, which is stored in the heap block's header, so String.length is a field read and a string may contain a zero byte harmlessly. A C string is char * plus the NUL-termination convention: strlen scans for the zero byte, so it is O(n), a string cannot contain one, and if the byte is missing — because a buffer was filled without room for it — strlen walks off the end into whatever follows. sizeof("hello") is 6 and strlen("hello") is 5, and that off-by-one is the source of an enormous number of buffer overflows.

OCaml's ^ allocates a fresh string of exactly the right size. C has no such thing: you supply a buffer and are responsible for it being large enough. Use snprintf, never sprintf — the n version takes the buffer size, refuses to write past it, and always NUL-terminates. The same distinction runs through the library: strncpy over strcpy, strncat over strcat, though strncpy has its own trap in that it does not always terminate. When the required size is not known in advance, snprintf with a null buffer returns the length it would have written, which is how you size a malloc.

first == second in C compares the two pointers, so it is asking whether they are the same object, not whether they hold the same text — and it prints 0 here even though both spell "hello". Content comparison is strcmp, which returns 0 for equal and a negative or positive number for ordering, so the test reads strcmp(a, b) == 0 and the inverted-looking sense catches people too. OCaml's = compares contents structurally and its == is physical identity, which is the same pair of operations with the safe one as the default.

OCaml checks every array access and raises Invalid_argument, which you can catch — the cost is a comparison per access, and Array.unsafe_get exists for the rare case where it matters. C checks nothing. numbers[10] reads whatever lives forty bytes past the array, which might be another variable, might be part of the stack frame, and might segfault; the behavior is undefined, which means the compiler is entitled to assume it never happens. Note also how the length is obtained: sizeof(numbers) / sizeof(numbers[0]) works only where the array's declaration is visible, because passing it to a function decays it to a pointer and sizeof then measures the pointer.

The parameter declaration const int numbers[] is a lie the language permits: it means exactly const int *numbers, and sizeof(numbers) inside the function measures a pointer. So the length must be passed alongside, and the two can disagree — a caller passing the wrong count produces an out-of-bounds read with no diagnostic anywhere. OCaml arrays carry their length in the heap block header, so Array.length works wherever the array does and the pair can never get out of step. This one difference is responsible for a large share of C's security history.

OCaml's int array array is an array of pointers to separate row arrays, so rows can have different lengths (a ragged array) and traversing costs an extra indirection per row. C's int grid[2][3] is one contiguous block of six integers — sizeof(grid) is 24 bytes — laid out row by row, which is why it is faster to walk and why it cannot be ragged. C's equivalent of OCaml's layout is int *grid[2], an array of pointers, and the difference between those two declarations is a classic source of confusion.

A C struct is a value laid out inline, and assigning one copies it field by field — which is why shifted = origin then modifying shifted leaves origin alone. There is no { record with … }, so the copy-then-assign above is the idiom. There is also no == for structs: comparing two requires memcmp, which is wrong in general because a struct may contain padding bytes with unspecified contents. OCaml's polymorphic = compares any two values structurally, which is one of the conveniences you are giving up.

An opaque struct — struct counter; declared but not defined in the header — is C's equivalent of an OCaml signature hiding type t. Callers can hold a struct counter * and pass it around, and cannot see or touch the fields, because the compiler does not know them. The costs are that the type can only ever be used through a pointer (its size is unknown), that it therefore must be heap-allocated, and that the caller must call the matching destroy function. This pattern is everywhere in real C libraries — FILE * is the one you already use.

C guarantees fields appear in declaration order and that each is aligned to its own requirement, so the compiler inserts padding bytes to make that true. A char followed by an int costs 8 bytes rather than 5. Both structs above are the same size here because the trailing padding rounds each to a multiple of the alignment, but in larger structs reordering fields from widest to narrowest genuinely shrinks them, which matters when you have millions. OCaml gives you no control and no visibility: every field of a record is one word, and floats-only records get a special unboxed representation the runtime chooses.

In OCaml a record is a heap block and passing it passes a pointer — always, invisibly, and safely, because the record cannot be modified. In C, passing by value copies every byte at each call, which is fine for a couple of words and wasteful for anything larger; passing const struct large * costs one word and states that the callee will not write. The -> operator is just (*value).a spelled conveniently. The convention worth adopting is const pointer for input, non-const pointer for output, which is how nearly every C API is shaped.

An OCaml variant guarantees three things at once: the tag and the payload cannot disagree, the payload of the wrong constructor is unreachable, and every case is handled. The C construction gives you none of them. Reading data.rectangle when kind is SHAPE_CIRCLE compiles and reinterprets the bytes; setting the tag and forgetting the payload compiles; and while GCC and clang do warn about a switch missing an enum case under -Wswitch, that warning disappears the moment a default label is added — which the trailing return here effectively does for safety. Every discriminated union in C is this, and it is why so much C uses a struct with unused fields instead.

OCaml's color is a real type with exactly three values, and there is no way to produce a fourth. A C enum is an integer type whose members are named constants, and any integer may be cast into it — the last line above passes 42 and the switch falls through to the fallback. That is why the return "unknown" is not defensive clutter but a necessity, and why C code that receives an enum from outside its own module has to validate it. It is also why the enum members here are prefixed: they live in the ordinary identifier namespace, not inside the type.

OCaml's option is a type: None is not an int and cannot be mistaken for one, whatever the value type is. C uses sentinels — -1 for an index, NULL for a pointer, 0 or EOF for a character — and each function chooses its own, documents it in prose, and relies on the caller checking. The approach breaks entirely when every value in the range is valid: a function returning any int has no spare value to mean "none", which is why so many C functions return a status code and write the real result through a pointer.

In OCaml everything is an expression, so if produces a value and the branches are required to agree on its type. C's if is a statement, so advice is declared uninitialized and then written in each branch — and if a branch is ever missed, it stays uninitialized and reading it is undefined behavior. The ternary operator condition ? a : b is C's expression form and does chain, though it reads poorly beyond two levels. Note the missing else hazard has no OCaml counterpart: there, an if without else must have type unit.

OCaml's | or-pattern says explicitly that several patterns share a branch. C achieves the same thing through fallthrough, which is the default: control runs from one case into the next until it meets a break or a return. That makes the or-pattern free and makes forgetting a break a real and common bug — modern compilers warn about implicit fallthrough between non-empty cases. C's switch also compares only integers and enum constants: no strings, no ranges, no destructuring, and no guards.

OCaml's loops run to completion, so stopping early means either writing a recursive function whose base case is the exit condition, or raising an exception and catching it just outside the loop — the second is idiomatic and cheap, and is what the anchor column shows. C's break and continue do the job directly, and goto is additionally respectable in one specific place: jumping to a cleanup label at the end of a function that has several failure points, which is the standard C answer to the absence of destructors and exceptions.

The difference is small and the C form is genuinely more direct for anything read-then-check shaped, such as consuming input until it runs out. OCaml has while and for and nothing else, so the same shape needs an extra flag or a recursive function. do { … } while (0) is also a C idiom with nothing to do with looping: it wraps a multi-statement macro so it behaves as a single statement inside an if without braces, which is one of the preprocessor's sharper edges.

An OCaml closure is a pair of a code pointer and the environment it captured, allocated automatically, so make_adder 10 returns something that remembers 10. A C function pointer is a bare address with nowhere to store anything, so the captured data must be passed alongside — conventionally as a void *context that the callback casts back to the right type. That is why qsort's comparator takes no context and is famously awkward, and why almost every other C callback API takes one. The cast is unchecked: passing the wrong context type compiles and misreads the bytes.

OCaml returns a tuple and destructures it, which costs one allocation and no ceremony. C's out parameter convention has the caller allocate the storage — here an ordinary local — and pass its address for the callee to write into. It is efficient and it is unchecked: nothing requires the callee to write to it, so a caller reading an out parameter after an error path may read an uninitialized value. C can also return a struct by value, which is closer to the OCaml version and is often the better choice; the out parameter dominates because it composes with the return-code error convention in the next section.

#include literally copies a file's text into yours before compilation, which is why headers need include guards, why compilation is slow, and why a macro defined in one header can break a completely unrelated file. #define is textual substitution with no types and no scope. Note the parentheses around (radius): without them, CIRCLE_AREA(1 + 1) expands to PI * 1 + 1 * 1 + 1, which is the classic macro bug. OCaml has nothing equivalent — its modules are a typed language construct, and its metaprogramming (ppx) operates on the parse tree with the types available.

#if and #ifdef remove code entirely, so it is never parsed and never type-checked — which is how a single C file supports Windows and Linux, and also why a typo inside an inactive branch can sit undetected for years. OCaml has no conditional compilation in the language: platform differences are handled by choosing different modules in the dune file, which means every alternative is still compiled and checked. The OCaml column's if debug then is a runtime check the optimizer will fold away, which covers the common case and cannot remove code that would not compile.

Because #include pastes a file's text, a header reached by two different paths — directly and through another header — would be pasted twice, and a duplicate struct definition is an error. The guard makes the second paste expand to nothing. OCaml has no equivalent problem: a module is compiled once into a .cmi/.cmo pair and referenced by name, so mentioning it from two places costs nothing and means nothing. This is one of the clearest illustrations of the difference between a real module system and a text-inclusion mechanism.

OCaml's swap is 'a array -> int -> int -> unit: one definition, every element type, fully checked, and the compiler knows the representation. The C version takes a void * and a sizeof, and works by copying bytes — which is genuinely generic and genuinely unchecked. Pass the wrong item_size and it silently corrupts memory; pass an array of the wrong type and nothing objects. This is how qsort and bsearch work, and it is why they take a comparator function pointer as well. The alternative C idiom is macros that generate a version per type, which is faster and type-checked and produces incomprehensible error messages.

qsort takes the array, the count, the element size and a comparator whose parameters are const void * — so the comparator casts, and a mismatch between the cast and the actual element type compiles silently and produces garbage. Note the return expression: writing first - second is the obvious form and is wrong, because the subtraction can overflow for large values, which is undefined behavior. (a > b) - (a < b) is the standard safe idiom. OCaml's List.sort takes a typed comparison over a known element type, and the polymorphic compare works on anything.

OCaml exceptions propagate automatically until something catches them, so a function that cannot handle an error simply does not mention it. C has no such mechanism: an error is a return code, and an unchecked return code is a silently ignored failure. That is why the out-parameter convention from earlier is so pervasive — the return slot is taken by the status, so the actual result needs somewhere else to go. There is setjmp/longjmp, which is a non-local jump and not an exception: it runs no cleanup, and using it to unwind past code holding a lock or a malloc leaks.

OCaml's Fun.protect runs its ~finally on every exit path including an exception, which is the whole problem solved. In C the standard answer is a single cleanup label at the end of the function and a goto from each failure point, so every resource is released exactly once regardless of where the function gave up. Note that free(NULL) is defined and does nothing, which is what makes the unconditional frees above correct. The other half of C error reporting is errno, a global set by library calls, which must be read immediately because the next call will overwrite it.

OCaml's assert raises Assert_failure carrying the file and line, so it is an ordinary exception you can catch — and it participates in the type system, since assert false has type 'a and can stand in anywhere. C's assert prints a message and calls abort(), terminating the process with no unwinding and nothing to catch. Both disappear from a release build — OCaml with -noassert, C when NDEBUG is defined — which is why an assert must never contain a side effect the program depends on; that code vanishes with it.

In OCaml every operation has a defined result: 10 / 0 raises Division_by_zero, an out-of-range index raises Invalid_argument, and integer arithmetic wraps. C has a category called undefined behavior in which the standard imposes no requirements at all — and modern optimizers use that, deleting a null check because a pointer was already dereferenced, or removing an overflow test because signed overflow "cannot happen". So the failure is not necessarily a crash at the guilty line; it can be code elsewhere quietly disappearing. The defenses are the sanitizers (-fsanitize=undefined,address), a high warning level, and writing checks before the operation rather than after.

In OCaml a let always binds something, and even an array must be created with an initial value for every slot. In C, int total; declares a variable whose contents are whatever the stack slot held, and reading it before assignment is undefined behavior — not "some arbitrary integer", which is why a debug build can behave differently from a release build. malloc likewise returns uninitialized bytes while calloc zeroes them. The rule is simple and worth following without exception: initialize at the point of declaration, and prefer calloc when zero is the sensible starting state.

The strict aliasing rule lets the compiler assume an int * and a float * never point at the same memory, which enables a great deal of optimization — and makes the classic pointer-cast reinterpretation undefined behavior, even though it looks like it obviously works and usually does until the optimizer is turned up. The defined way to reinterpret bytes is memcpy, which compilers recognize and compile to nothing. OCaml has no way to do this at all: conversions are explicit functions with defined semantics, and reinterpreting a representation requires Obj.magic, which is exactly as dangerous as it sounds.

OCaml 5's Domain.spawn takes a closure returning any type and Domain.join returns that value, typed. A pthread function must have signature void *(*)(void *), so both the argument and the result are untyped pointers the callee casts — and the storage they point at must outlive the thread, which is why the total above lives in main's frame rather than the thread's. Note also that OCaml 5 domains each carry a minor heap and a share of the collector, so they are heavier than a pthread and you create a handful rather than hundreds.

The two columns are structurally the same, and the difference is what happens when the locking is removed. In OCaml 5 the runtime guarantees a data race cannot corrupt memory — you get a wrong number, which is bad but bounded. In C an unsynchronized read and write to the same object is undefined behavior, so the compiler may cache the value in a register, reorder the accesses, or assume the race does not happen; the result is not merely a wrong count but a program with no defined meaning. C11 added <stdatomic.h>, which gives properly defined atomic operations and is what you want for a counter like this one.

OCaml 5's Atomic and C11's <stdatomic.h> both give lock-free read, write, exchange and compare-and-set on a single location, and both are what you want for a shared counter instead of a mutex. The important difference is that C exposes the memory ordering — atomic_fetch_add_explicit takes a parameter choosing between sequential consistency, acquire/release and relaxed — while OCaml's Atomic is sequentially consistent and offers no choice. That is a fair summary of the whole pair: C hands you the machine, and OCaml picks the safe default.

An external declaration gives an OCaml type to a C function; the compiler emits a call and trusts you completely, because nothing checks that the C function's signature matches the OCaml type you claimed. On the C side, value is the universal OCaml representation: an odd word is a tagged immediate integer (hence Long_val shifting right and Val_long shifting left and setting the low bit), and an even word is a pointer to a heap block. That one-bit tag is exactly why an OCaml int is 63 bits rather than 64 — a fact from the very first section of this page, explained here.

OCaml's collector is moving: allocating can relocate live values and rewrite every reference it knows about. It knows about the OCaml stack and the globals; it knows nothing about a C function's locals. So any value held in C across a call that might allocate must be registered as a root with CAMLparam (for parameters) and CAMLlocal (for locals), and released with CAMLreturn. Skip it and the code works perfectly until a collection happens to occur at that moment, after which you are holding a pointer to where the value used to be. Note also String_val: the pointer it yields is only valid until the next allocation, for exactly the same reason.

Most of the classic reasons to drop into C are already answered in OCaml: Bytes is a mutable byte buffer, Bigarray wraps externally-managed memory without copying, and ocamlopt produces native code that is frequently within a small factor of C. The reasons that remain are real but specific — binding an existing C library, which is by far the most common; needing precise control of memory layout or lifetime; and running somewhere OCaml's runtime cannot go, such as a kernel or a very small embedded target. Every FFI boundary is also a place the type system stops, so the smaller the surface the better.