# What “Exported” Means

### Exported Functions

An exported function is a function made visible outside the current Zig program.

Normally, functions only exist inside the compiled program itself.

Example:

```zig
fn add(a: i32, b: i32) i32 {
    return a + b;
}
```

This function is internal.

Other programs cannot see it.

An exported function changes that.

Example:

```zig
export fn add(
    a: i32,
    b: i32,
) i32 {
    return a + b;
}
```

Now the function becomes part of the program’s external binary interface.

Other languages and programs may call it.

## What “Exported” Means

When a program is compiled, functions become machine-code symbols.

Most symbols are private.

Exporting a function makes its symbol public.

Conceptually:

```text
normal function
  -> internal only

exported function
  -> visible externally
```

This is essential for:

- shared libraries
- plugins
- C interoperability
- operating systems
- embedded firmware
- game engines

## A Simple Exported Function

```zig
export fn multiply(
    a: i32,
    b: i32,
) i32 {
    return a * b;
}
```

The keyword:

```zig
export
```

tells the compiler:

```text
make this symbol externally visible
```

## Exporting Shared Libraries

Exported functions are commonly used when building dynamic libraries.

Example conceptually:

```text
math.dll
libmath.so
libmath.dylib
```

These libraries expose functions other programs can call.

Example exported API:

```zig
export fn add(
    a: i32,
    b: i32,
) i32 {
    return a + b;
}
```

A C program could call this function.

## Why Exported Functions Usually Use C ABI

Binary compatibility matters.

Most exported APIs use:

```zig
callconv(.C)
```

Example:

```zig
export fn add(
    a: i32,
    b: i32,
) callconv(.C) i32 {
    return a + b;
}
```

This ensures compatibility with C and many other languages.

Without ABI agreement, external calls may fail.

## Exported Symbols

Suppose we compile:

```zig
export fn hello() void {

}
```

The binary may contain a symbol like:

```text
hello
```

External programs can locate and call this symbol dynamically.

## Exported Functions and Shared Libraries

Building a shared library conceptually:

```bash
zig build-lib math.zig -dynamic
```

This produces a dynamic library.

Inside:

```zig
export fn add(
    a: i32,
    b: i32,
) callconv(.C) i32 {
    return a + b;
}
```

Now other languages may load the library and call `add`.

## Example: Calling from C

Zig library:

```zig
export fn square(
    x: i32,
) callconv(.C) i32 {
    return x * x;
}
```

C program:

```c
#include <stdio.h>

int square(int x);

int main() {
    printf("%d\n", square(5));
}
```

This interoperability is one of Zig’s major strengths.

## Exporting Variables

Zig can export variables too.

Example:

```zig
export var counter: i32 = 0;
```

Now external programs may access:

```text
counter
```

directly from the binary.

This is less common but sometimes useful.

## Exported Constants

Constants can also be exported.

Example:

```zig
export const version: i32 = 1;
```

This allows external systems to inspect metadata.

## Export Names

By default, the exported symbol name matches the Zig function name.

Example:

```zig
export fn hello() void {

}
```

exports:

```text
hello
```

Some systems allow custom exported names.

This matters when integrating with existing APIs.

## Exporting for Plugins

Plugins commonly use exported entry points.

Example conceptually:

```zig
export fn pluginInit() void {

}
```

A host application dynamically loads the library and searches for:

```text
pluginInit
```

This is common in:

- game engines
- browsers
- editors
- audio systems

## Exported Functions and Operating Systems

Operating systems frequently depend on exported symbols.

Examples:

- kernel APIs
- driver interfaces
- bootloader entry points
- system calls

Low-level software heavily relies on stable binary interfaces.

## Exported Functions and WASM

WebAssembly modules also use exports.

Example conceptually:

```zig
export fn update() void {

}
```

JavaScript may call:

```javascript
wasm.exports.update()
```

Exports are one of the core mechanisms in WASM interoperability.

## Exported Functions and Embedded Systems

Embedded firmware often exports known entry symbols.

Examples:

```text
ResetHandler
InterruptHandler
main
```

The hardware or bootloader expects exact symbol names.

## Public vs Exported

Important distinction:

| Keyword | Meaning |
|---|---|
| `pub` | visible to Zig modules |
| `export` | visible at binary level |

Example:

```zig
pub fn helper() void {

}
```

Other Zig files can use it.

But external programs cannot.

Example:

```zig
export fn api() void {

}
```

Now the function becomes externally visible in the compiled binary.

## Using Both `pub` and `export`

Sometimes both are used:

```zig
pub export fn api() void {

}
```

This makes the function visible:

- inside Zig modules
- outside the binary

## Exported Functions and Safety

Exported functions should use stable, simple types.

Good exported API types:

| Good | Why |
|---|---|
| integers | stable ABI |
| floats | stable ABI |
| pointers | stable ABI |
| C structs | predictable layout |

Bad exported API types:

| Risky | Why |
|---|---|
| Zig-specific internals | ABI instability |
| complex generic types | language-dependent |
| allocator-heavy abstractions | ownership confusion |

Stable binary interfaces require careful design.

## Name Mangling

Some languages modify symbol names internally.

This is called name mangling.

C avoids heavy mangling, which is why C ABI compatibility is so universal.

Zig exported C-style APIs usually avoid complicated mangling too.

## Dynamic Loading

Programs may load exported functions at runtime.

Example conceptually:

```text
load library
find symbol
call function
```

This is how many plugin systems work.

## A Complete Example

```zig
const std = @import("std");

export fn add(
    a: i32,
    b: i32,
) callconv(.C) i32 {
    return a + b;
}

export fn subtract(
    a: i32,
    b: i32,
) callconv(.C) i32 {
    return a - b;
}

pub fn main() void {
    const x = add(10, 5);
    const y = subtract(10, 5);

    std.debug.print(
        "{} {}\n",
        .{ x, y },
    );
}
```

Output:

```text
15 5
```

The functions work normally inside Zig while also being available externally.

## Mental Model

An exported function is:

```text
a public machine-level entry point
```

Normal functions exist only inside the program.

Exported functions become visible to:

- other programs
- shared libraries
- operating systems
- foreign languages
- plugin systems

This makes exported functions one of the foundations of interoperability and systems programming.