Java.CodeCompared.To/C

Three things to register from four lines. #include <stdio.h> is not an import: the preprocessor pastes that file into yours before the compiler sees anything, which is why the Headers section exists. main returns int, and that value is the process exit status the shell reads. And void in the parameter list means "no parameters" — leaving it empty means something subtly different in older C and is worth not learning the hard way.

The trade runs both ways and it is worth being fair about. C wins outright on startup and on predictability: no warmup, no pause, no heap to size. The JIT wins where it can see behavior a static compiler cannot — it inlines the one implementation an interface actually has and deoptimizes if another appears — which is why a long-running Java service can outrun naively written C. What you lose is "compile once, run anywhere": a C binary is for one architecture and one operating system, so the portable artifact is the source.

Four failure modes arrive with it, and Java has none of them: leaking (never freed), use-after-free (used after it was), double-free (freed twice), and freeing a pointer that was not malloc'd. Only the first is merely a waste; the other three are undefined behavior. Setting the pointer to NULL after freeing turns a use-after-free into an immediate crash instead of silent corruption, which is why the line is there. Run everything under a sanitizer — -fsanitize=address — from the first day.

The rule that follows is the one to internalize immediately: never return a pointer to a local. The storage is reused as soon as the function returns, so the pointer is dangling and everything after that is undefined. Return the struct by value (C copies it), or take a pointer to storage the caller owns, or malloc. In Java you cannot make this mistake because there are no stack objects to point at.

The discipline that works is to decide, for every allocation, exactly one piece of code that owns it and frees it. A function that returns a malloc'd pointer is handing over ownership and must say so in its documentation, because the type cannot. Where C++ would use unique_ptr and Rust the borrow checker, C has convention and review — which is why leak checking (valgrind, -fsanitize=leak) belongs in the build rather than in a heroic debugging session later.

The three-way distinction is worth spelling out because Java collapses it to two. Java passes a reference by value: the callee can modify the object and cannot replace it. C lets you pass the struct by value (a real copy — no aliasing at all, which Java cannot do), or a pointer (the callee modifies yours), or a pointer to a pointer (the callee can replace yours). -> is (*pointer).field, and it is the operator you will type most.

This is the capability that makes C fast and dangerous in the same breath: walking a buffer with a moving pointer is idiomatic, costs nothing, and is checked by nobody. Two rules keep it survivable — arithmetic is only defined within an array (and one past its end), and comparing or subtracting pointers into different objects is undefined even though it will appear to work. The reason Java forbade all of it is that a collector must be able to move objects, which it cannot do if the program is holding addresses.

So every pointer that could be NULL is checked before use, by you, every time. The habits that make this workable: check what malloc returns, check what any function returning a pointer returns, and document which parameters may be NULL since the type cannot say. A segmentation fault has no stack trace of its own — you get one from a debugger or from a sanitizer build, which is another reason to compile with -g -fsanitize=address while developing.

The rule for new code is to use <stdint.h> — int32_t, uint64_t, size_t for sizes and indices, ptrdiff_t for pointer differences — and to leave bare int for loop counters and small values. The other half of the difference is that unsigned types exist here, which Java has none of. They wrap by definition rather than overflowing, and mixing signed and unsigned in one comparison converts the signed one — so -1 < 1u is false, which is the classic C bug that no Java experience prepares you for.

The other absences worth naming up front: no boolean until C99 added <stdbool.h> (and it is an integer underneath, so any non-zero value is true), no method overloading, no namespaces, no destructors, no exceptions, no String class, and no standard collections at all — no list, no map, no set. A C project either writes its own or picks a library, and this is the single biggest day-to-day difference in how much code you write.

Three consequences that all bite. strlen walks the bytes looking for the terminator, so it is O(n) and calling it in a loop condition is a classic accidental quadratic. The terminator is a convention — nothing enforces it, and a byte sequence without one makes every string function run off the end. And the buffer is yours: snprintf takes the size and truncates, where strcpy and sprintf do not and are how buffer overflows happen. Use the n forms, always.

The return value is a sign, not a boolean: negative when the first sorts before the second, positive when after, zero when equal — so it drops straight into qsort. strncmp bounds the comparison, which matters when either side might not be terminated. And unlike Java, where literals are interned so == sometimes accidentally works, C makes no promise at all about whether two identical literals share an address.

This is the root of the most consequential difference between the languages. Java checks every index because it always knows the length; C cannot check because by the time your function has the array, the length does not exist. Reading values[10] from a four-element array is not an exception, it is whatever those bytes happen to be — and writing there corrupts something else. Keep the pointer and the count together, in a struct if the pair travels, and never let them separate.

That layout difference is most of why numeric C outruns naive numeric Java: the block is contiguous, so a cache line prefetches the next elements, while Java's rows may be anywhere. Java can get most of it back with a flat int[] and manual index arithmetic, which is exactly what serious numeric Java does. The cost on the C side is that a rectangular array cannot be ragged, and passing one to a function requires all dimensions but the first in the parameter type.

The naming convention does the work a class did: rectangle_area, rectangle_scale, rectangle_free are what a Java reader would find as methods on Rectangle. Encapsulation is available through an opaque struct — declare the type in the header without its fields and define it in the implementation file, so callers can only hold a pointer and must go through your functions. That is the C equivalent of private, and it is the pattern every serious C library uses. The .width = spelling is a designated initializer, from C99, and is worth using because it survives a field being reordered.

Two follow-ons. Passing a struct to a function copies it too, so a large struct passed by value is a real cost that nothing in the call site reveals — which is why C code passes const struct Thing * almost everywhere. And the copy is shallow: if the struct contains a pointer, both copies now point at the same thing, and both will try to free it unless you decided which one owns it. Java's equivalent question does not arise, because there are no value copies at all.

Notice what the comparator has to do: it receives const void * and casts to the type it believes is there, so nothing checks that qsort was given a comparator matching the array. That is the shape of every C callback. The absences are real — no closures, so context reaches a callback through an extra void *user_data parameter that most APIs provide by convention, and no overloading, so a function pointer type must match exactly. The subtraction trick in the return avoids the overflow that a - b would risk.

The file-scope meaning is the one to adopt as a habit: mark every function and global that is not part of your header static, so it cannot be linked to from elsewhere. Without it, two files that both define helper collide at link time — C has no namespaces, so every non-static name is in one global pool, which is why library functions are prefixed (png_read_info, sqlite3_open). The function-local meaning is worth being careful with: a static local is shared by every caller, so it is not thread-safe.

🚨 Nothing makes the caller check. Delete the if and the program compiles, runs, and carries on with an untouched variable — which is the single largest source of real C bugs, and the reason -Wall -Wextra and static analysis are not optional. Two other conventions you will meet: errno, a thread-local integer that library functions set (check it only after a call has already reported failure), and goto cleanup — the one respectable use of goto, where every error path jumps to a single block that frees what was allocated. That is C's finally.

It exists because the alternative is worse — releasing three things on five different error paths means fifteen chances to forget one, and that is where leaks come from. The rules that keep it readable are to declare and zero-initialize everything before the first goto (jumping over an initialization is an error), to free in reverse order of acquisition, and to have exactly one label. Any C programmer will read this instantly; it is the one place the profession stopped arguing about goto.

The mental model to build: a header declares (types, function prototypes, macros) and a .c file defines. Every file that wants to call your function includes the header; the linker matches the calls to the one definition afterwards. That also explains C's two error messages, which a Java programmer meets as one — "implicit declaration" comes from the compiler and means it never saw the promise, while "undefined reference" comes from the linker and means the promise was never kept.

Those parentheses in SQUARE are the canonical example: written value * value, the call SQUARE(3 + 1) expands to 3 + 1 * 3 + 1, which is 7. A macro also evaluates its argument as many times as it appears, so SQUARE(index++) increments twice. Prefer static const int and static inline functions, which the compiler type-checks; keep the preprocessor for include guards and #ifdef platform selection, which genuinely have no alternative.

🚨 The part that surprises everyone is that the optimizer is allowed to assume it never happens. A null check written after a dereference can be deleted, because if the pointer were null the program would already have been undefined — so the compiler concludes it cannot be. This is why "it worked in the debug build" is a sentence C programmers say. The defenses are real and they are not optional: -Wall -Wextra, -fsanitize=address,undefined during development, and a static analyzer in the build.

The habit that removes the whole class of bug is to initialize at the point of declaration, every time: int count = 0;, struct Thing thing = {0};, char buffer[64] = "";. Use calloc when you want zeroed heap memory and malloc when you are about to fill every byte anyway. This is a favorite of security researchers, because uninitialized memory frequently contains something interesting from a previous allocation.

The pieces map onto C ideas directly. An Arena is a scoped allocator whose close frees everything at once — the goto cleanup block, as a language feature. A MemorySegment is a pointer that carries its length and is bounds-checked, which is the pointer-plus-count pair from the Arrays section made into one value. A FunctionDescriptor is the prototype, written where the linker can use it. The rules that carry over are the ones this whole page has been about: do not keep a segment past the arena that owns it, and mind which thread calls in.

The practical advice that follows is narrow and worth taking. Keep the boundary small — a few coarse calls rather than many fine ones, since each crossing costs more than a Java call. Copy data across rather than holding pointers into the Java heap, unless you have measured that you cannot afford to. Validate on the C side rather than trusting the caller. And test the native library on its own, with a sanitizer build and its own test program, because a crash inside the JVM is far harder to diagnose than the same crash in a small C program.