Fortran.CodeCompared.To/C

A Fortran program is a single program name ... end program name block. C has no dedicated program wrapper — instead, execution always begins at a specific function named main, which must explicitly return 0 to signal success to the operating system (Fortran needs no equivalent statement; falling off the end of the program implies success).

Fortran comments use !, running to the end of the line. C has two comment forms: /* ... */ block comments (available since C89, can span multiple lines but do not nest) and // single-line comments (added in C99, matching Fortran's style more closely).

Both languages agree here, unlike R or Julia: Fortran and C are both compiled ahead of time to a native binary before they run, with no JIT and no separate interpreter step. gfortran example.f90 -o example and gcc example.c -o example are the same two-step compile-then-execute workflow.

Fortran with implicit none requires every variable to be declared with an explicit type. C has always required this unconditionally, with no equivalent of Fortran's pre-implicit none implicit-typing history — every C variable has always needed a declared type before use, in every version of the language.

Both languages let a programmer choose an exact integer width deliberately: Fortran's integer(kind=int32)/integer(kind=int64) from iso_fortran_env map directly onto C's int32_t/int64_t from <stdint.h> — the same idea, the same widths, a near-identical mechanism.

Fortran's real and double precision map directly onto C's float and double — both languages give the programmer explicit 32-bit and 64-bit IEEE 754 floating-point types with no default-precision ambiguity, right down to needing a suffix to mark a single-precision literal (3.14159f in C, 3.14159e0 in Fortran) versus the double-precision default.

Fortran has had a genuine logical boolean type since its earliest days. C did not gain a real boolean type until C99's <stdbool.h> header (which defines bool, true, and false as macros over _Bool) — before that, C conditions used plain int, where any nonzero value meant true. A Fortran programmer's reflex that "of course there's a boolean type" needs the explicit #include <stdbool.h> in C.

Both languages agree on fixed-width character storage, unlike R or Julia's dynamic strings — a genuine similarity between two low-level languages. The size mismatch to watch: Fortran's character(len=10) holds exactly 10 characters, blank-padded; C's char name[11] needs one extra byte beyond the 10 visible characters for the mandatory null terminator ('\0'), a concept Fortran strings have no equivalent of at all.

Fortran's pointer attribute requires the thing it points to be explicitly marked target first, and association uses the distinct => operator (never plain =) so the compiler can tell "point at this" apart from "copy this value." C has no such restriction — any variable's address can be taken with & at any time with no prior declaration, and dereferencing uses the prefix * operator rather than a bare name.

Fortran's parameter attribute and C's const qualifier both mark a value the compiler rejects any attempt to reassign — a close match. One difference: C's preprocessor also offers #define PI 3.14159265358979 as an older, type-unchecked alternative with no Fortran equivalent at all, since Fortran has no preprocessor built into the base language.

Both languages use a bare = for assignment. C additionally has compound assignment operators (+=, -=, and so on) and pre/post increment (count++), none of which Fortran has — Fortran always spells out count = count + 1 in full.

Both languages let a comma-separated list of names share one type declaration — Fortran's integer :: a, b, c and C's int a, b, c; read almost identically.

Fortran arrays default to 1-based indexing (the first element is numbers(1)); C arrays are always 0-based (the first element is numbers[0]), with no way to change this. A 5-element array's last valid index is 5 in Fortran but 4 in C — one of the most common off-by-one traps when translating an algorithm between the two languages.

This is the headline structural difference between these two languages. Fortran stores multi-dimensional arrays column-major: the first index varies fastest in memory, so a 2×3 array's elements sit in memory in the order (1,1), (2,1), (1,2), (2,2), (1,3), (2,3). C stores arrays row-major: the last index varies fastest, so a 2×3 array's elements sit in memory as (0,0), (0,1), (0,2), (1,0), (1,1), (1,2) — the opposite convention entirely. This matters enormously in practice: looping in the wrong nesting order for a language's storage layout causes cache-unfriendly memory access patterns that can slow numeric code down by an order of magnitude, and passing a matrix between Fortran and C code (a common scenario when Fortran numerical libraries are called from C, or vice versa) silently transposes it unless the interop code explicitly accounts for the difference.

A Fortran assumed-shape array argument (values(:)) genuinely knows its own size — size(values) works correctly inside the subroutine because Fortran passes array metadata (a "descriptor"), not just a raw address. A C array parameter, by contrast, immediately "decays" into a plain pointer to its first element the moment it crosses a function boundary — sizeof(values) inside printArraySize returns the size of a pointer (8 bytes on a 64-bit system), not the size of the original 5-element array. This is why virtually every C function that takes an array also takes a separate integer size parameter — the array itself cannot tell you how big it is.

Neither language checks array bounds by default — reading or writing past the end of an array is undefined behavior in both, silently corrupting memory or crashing unpredictably rather than raising a clean error. The one asymmetry: gfortran offers an opt-in -fcheck=bounds compile flag that adds bounds checking for debugging; standard C has no equivalent flag at all (some platforms offer sanitizers like AddressSanitizer as a separate, more heavyweight tool, but nothing built into the compiler the way Fortran's flag is).

Fortran indexes a 2D array with comma-separated subscripts inside one set of parentheses: matrix(row, col). C uses a separate bracket pair per dimension: matrix[row][col]. Watch the index shift alongside the row-major/column-major difference: Fortran's matrix(1, 2) (1-based) is C's matrix[0][1] (0-based) for the logically equivalent "first row, second column" element.

Fortran treats an array as a value you can operate on directly — prices = prices * 0.9 scales every element in one statement with no loop. C, like Pascal, has no whole-array operators at all; scaling every element always requires an explicit for loop written by hand.

Fortran's intent(in) and C's const qualifier both tell the compiler a parameter is read-only, rejecting any attempt to modify it inside the function. Plain scalar C parameters like score are always read-only in the caller's sense anyway (C passes by value, so modifying the local copy never affects the caller) — const matters most for pointer parameters like personName, protecting the pointed-to data from modification through that pointer.

This is half of the headline difference. Fortran's intent(out) parameter is really a pointer under the hood, but the syntax hides that completely — area_out = ... looks like an ordinary assignment. C has no equivalent implicit mechanism: because C passes by value, "returning" a second value through a parameter requires the caller to explicitly pass a pointer (&area) and the function to explicitly dereference it on every write (*areaOut = ...). Forgetting either the & at the call site or the * inside the function is a common, and sometimes silently wrong-but-compiling, C bug that Fortran's intent(out) mechanism makes structurally impossible.

This is the other half of the headline difference, and the single most consequential one for anyone porting code between the two languages. Fortran passes every argument by reference by default — even a plain integer parameter with no special attribute is implemented as a hidden pointer, so a subroutine that reassigns its parameter silently changes the caller's variable too, unless the parameter is marked intent(in) (which is a promise the compiler checks, not a change in the underlying calling convention). C passes every argument by value by default — a function can freely reassign its own parameter with zero effect on the caller, and modifying the caller's actual variable requires an explicit pointer parameter, as the second function here demonstrates. A Fortran programmer's reflex that "the subroutine already sees my real variable" is exactly backwards for C.

Fortran's null() intrinsic and C's NULL macro (from <stddef.h>, or several other standard headers) both represent a pointer that points to nothing. Fortran checks this safely with the dedicated associated() intrinsic; C compares directly against NULL with an ordinary equality operator, since a C pointer is just an address with no separate "association state" the language tracks specially.

Fortran array access always goes through the array's own name and an index — there is no way to obtain a raw, incrementable memory address and "walk" it manually the way C does. In C, *(pointer + 2) is defined to mean exactly the same thing as pointer[2], and a pointer variable itself can be incremented (pointer++) to advance to the next element's address — a genuinely lower-level capability with no Fortran counterpart, and a common source of C bugs when the arithmetic drifts past the array's actual bounds.

Both languages agree: plain / performs integer division (truncating toward zero) when both operands are integers, and the remainder operator (mod() in Fortran, % in C) has matching truncating semantics in both languages since C99 standardized truncation-toward-zero for negative operands.

Fortran has a dedicated ** exponentiation operator built into the language. C has no exponentiation operator at all — raising a number to a power always goes through the pow() function from <math.h>. (A common trap for programmers used to other C-family languages: ^ in C means bitwise XOR, not exponentiation — writing 2 ^ 10 compiles without error but silently computes something completely unrelated.)

Fortran's sqrt, sin, and other math functions are intrinsic — always available with no import. C requires #include <math.h> for the equivalent functions, and on many platforms/toolchains also requires linking against the math library explicitly with the -lm compiler flag — a two-part requirement (header AND linker flag) that Fortran has no equivalent of at all.

Fortran's nint()/int()/floor()/ceiling() map directly onto C's round()/trunc()/floor()/ceil() from <math.h> — same four operations, nearly the same names, both requiring the header import in C that Fortran does not need.

Fortran concatenates with the dedicated // operator in a single expression. C has no concatenation operator whatsoever — building a combined string always means an explicit strcpy() into a large-enough destination buffer followed by one or more strcat() calls, each of which re-scans the destination for its existing null terminator, an even more manual and error-prone process than Fortran's already-explicit //.

Fortran needs len_trim() to get the length ignoring trailing blank padding. C's strlen() counts characters up to (but not including) the null terminator — conceptually similar to len_trim()'s "ignore the meaningless part," except C's meaningless part is everything after a single sentinel byte rather than trailing spaces.

Fortran's bracket syntax phrase(1:5) extracts a substring directly, with the result automatically sized. C has no substring operator or function at all — extracting one requires strncpy() into a separate buffer, and the programmer must remember to add the null terminator manually, since strncpy() famously does not add one if the source is at least as long as the requested count. Reaching a substring that runs to the end of the string is simpler: plain pointer arithmetic (phrase + 6) already produces a valid, null-terminated C string starting from that offset.

Fortran strings carry their length as separate metadata (the declared len=) — there is no in-band sentinel character marking the end, and a Fortran string can freely contain any byte value, including one that would be a null byte. C strings are exactly the opposite: the only way any C string function knows where a string ends is by scanning for a null byte ('\0'), so every C character buffer needs one extra byte beyond its visible content, and every string operation that overwrites or omits that terminator causes the next read to run past the buffer looking for a terminator that may not exist for a long, dangerous distance. This single design difference is the root cause of an enormous fraction of historical C security vulnerabilities, and has no Fortran parallel at all.

Both languages support a flat multi-branch chain with matching structure: Fortran's if / else if / else / end if and C's if / else if / else with brace-delimited blocks read almost identically.

Fortran's select case never falls through to the next branch — each case is fully independent, just like most modern languages. C's switch falls through by default: without an explicit break statement at the end of each case, execution continues into the next case's code regardless of whether its label matches. Forgetting a single break is one of the most common and notorious C bugs, with no Fortran equivalent risk at all.

Fortran surrounds its logical operators with dots (.and., .or., .not.). C uses the symbols &&, ||, ! — both operators short-circuit (stop evaluating as soon as the result is determined) in both languages.

Fortran's do i = 1, 5 declares the start and (inclusive) end of a count in one compact clause. C's for loop spells out all three parts explicitly and separately: an initializer (int i = 1), a continuation condition (i <= 5, using <= since C has no inclusive-range shorthand), and an increment (i++) — considerably more verbose, but correspondingly more flexible, since each of the three parts can be any valid C expression, not just a simple count.

Fortran's do while (condition) and C's while (condition) { } are functionally identical — both test the condition before each iteration and may run zero times.

C's do { ... } while (condition); tests its condition after the loop body, guaranteeing at least one execution — the classic post-tested loop. Fortran has no direct equivalent construct; a Fortran programmer must simulate one with a pre-tested do while and a manually managed flag (as shown here), or an unconditional do with an if/exit placed at the bottom of the loop body.

Fortran's cycle (skip to the next iteration) and exit (break out of the loop) map onto C's continue and break — the same two concepts, different names for the first one.

Fortran distinguishes two kinds of callable unit: a subroutine (called with call, returns nothing, communicates through arguments) and a function (called like an expression, returns exactly one value via result()). C unifies both into a single concept — an ordinary function — with a void return type standing in for "returns nothing," playing the role Fortran's subroutine keyword plays, but with no separate keyword or calling syntax needed.

Fortran's explicit interface block and C's function prototype (int square(int n);) serve the same purpose: telling the compiler a function's signature before its actual definition appears later in the file (or in a different file entirely), so calls before that point can still be checked. Fortran only needs this for genuinely external procedures — internal contains procedures are automatically visible with no interface block required, since the compiler processes the whole program together.

Fortran can overload a single generic name across multiple type-specific procedures with a generic interface block — calling double_value with an integer or a real argument resolves to the matching specific procedure automatically. Standard C has no function overloading mechanism whatsoever: two functions can never share a name no matter how different their parameter types are, so each type combination needs its own distinctly-named function, as shown here. C is genuinely more restrictive than Fortran on this point.

Fortran requires the explicit recursive keyword before a function or subroutine may call itself — an important safety default, since an ordinary Fortran subprogram is not guaranteed reentrant otherwise. C has no such requirement or keyword at all: every C function may call itself freely, with no special declaration needed.

A Fortran type and a C struct both group named, typed fields into a single value, accessed with a member operator — % in Fortran, . in C. C's typedef struct { ... } Name idiom lets the type be referred to as Point rather than the more verbose struct Point everywhere afterward.

Both languages combine arrays and structs the same way: an array whose element type is a derived type/struct, accessed by combining the subscript and the member operator — points(1)%x versus points[0].x, differing only by the 1-based/0-based index shift already familiar from ordinary arrays.

Both languages agree: a plain Fortran type and a plain C struct hold only data by default, with no methods bound to them at all — behavior always lives in ordinary free functions that take the value as a parameter, as shown here. (Later Fortran standards did add optional type-bound procedures for a more object-oriented style, but the plain data-only struct/type shown here remains each language's simplest and most common default.)

Fortran's allocate()/deallocate() and C's malloc()/free() both manage memory manually with no garbage collector in either language — a real point of agreement, unlike R or Julia. The details differ sharply: Fortran's allocate(items(3)) already knows it is allocating 3 integers; C's malloc() only knows a raw byte count, so the programmer must compute itemCount * sizeof(int) explicitly, and malloc() can return NULL on failure (which the caller must check) where Fortran's allocate instead has an optional stat= argument for the same purpose.

print *, ... in Fortran infers default formatting for each value automatically. C's printf() requires an explicit format specifier per value (%d for an integer, %f for a floating-point value) — more verbose, but giving precise control over the output that Fortran's write(*, '(format)') descriptors provide separately from the simpler print *, form.

Fortran's storage_size() intrinsic reports a variable's size in bits. C's sizeof operator reports a variable's size in bytes — both answer "how much memory does this take," just in different units, and sizeof is a compile-time operator in C (evaluated at compile time whenever possible) rather than an ordinary function call.

Fortran identifies an open file by an arbitrary integer unit number. C identifies one by a FILE * pointer returned from fopen(), which must be checked against NULL to detect a failed open (Fortran instead uses an optional iostat= argument for the same purpose). Both require a real filesystem and cannot run in the browser sandbox.

Both languages have some notion of undefined behavior, but C's is dramatically broader and more consequential in practice: signed integer overflow, out-of-bounds array access, using an uninitialized variable, dereferencing a NULL pointer, and violating strict aliasing rules are all undefined behavior in C, and modern optimizing compilers are permitted to assume none of them ever happen — sometimes eliminating a programmer's explicit safety check entirely because the compiler proves the "impossible" branch it guards against is technically undefined behavior. Fortran's undefined-behavior surface (mainly out-of-bounds access without -fcheck=bounds, and a handful of aliasing rules around intent) is considerably narrower.

Both an integer(kind=1) in Fortran and an int8_t in C wrap silently on overflow with no error. One asymmetry worth knowing: unlike Fortran, C's signed integer overflow is technically undefined behavior per the language standard (even though it wraps predictably on virtually every real machine and compiler) — the explicit cast shown here keeps the arithmetic in int8_t to sidestep any ambiguity, since plain C arithmetic on small integer types is first promoted to int before the operation happens.

Both languages agree, unlike R or Julia: nothing frees dynamically allocated memory automatically in either Fortran or C. Forgetting deallocate() in Fortran or free() in C both leak memory for the remaining lifetime of the process, with no garbage collector ever stepping in to clean up an orphaned allocation in either language.

Fortran's use module_name reads compiler-generated module information directly from the module's own compiled form (a .mod file), so the interface a caller sees can never drift from the real implementation — the compiler guarantees they match. C headers are just manually written, separate text files declaring what the corresponding .c file is supposed to contain; nothing enforces that a header's declared function signatures actually match the real definitions elsewhere, and a header that falls out of sync with its implementation is a real, if increasingly rare with modern tooling, category of C bug that Fortran's module system makes structurally impossible.